Re: CVS commit: src/usr.bin/make

[christos%zoulas.com@localhost (Christos Zoulas)]

On Feb 6, 10:50pm, ross%netbsd.org@localhost ("r.o.s.s") wrote:
-- Subject: Re: CVS commit: src/usr.bin/make

| Sure, maintaining the exact getopt API would be nice, though there
| is a counter-argument that, given a custom implementation, it might
| be better to be upfront and clear about it. It's easier to read
| and work on: what you see is what you get.  I can rework it to call
| getopt_custom() or something, but that's not clean either, because
| both main() and getopt_custom() would be making assumptions about
| the others internal implementation. It seems better just to explicitly
| parse the args, which took only a fraction of the lines it took to
| talk about it.
| 
| I kept the getopt optstring, so it's functionally similar, it just
| doesn't use quite the same binding.
| 
| If we do keep the general API, the name still has to be changed
| because there is no getopt.h, it's in unistd.h and so there is no
| good way to declare one that will always match local headers.
| 
| But the worst problem is the coverage issue, it's dangerous to
| intentionally have two implementations and run one of them only in
| certain obscure situations. I'm very surprised to hear you advocate
| that, with a build kludge on top of it. We've accepted portability
| as a goal, this is a consequence. 
| 
| This is a true case where a custom implementation is called for.
| Unlike 99.?% of the arg-parsing programs, this one does special
| non-posix stuff that isn't fully specified even in our getopt.
| Rather than asking the library to work anyway, in this case I would
| argue that the proper and standard-conforming approach is to
| custom-code this one exceptional case.
| 

Fine, you've convinced me. Lets leave it the way it is now.

christos