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

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

In article <20040206212300.10815.qmail%mail.netbsd.org@localhost>,
r.o.s.s <ross%netbsd.org@localhost> wrote:
>> From Perry
>> Why not just include our getopt in the compat library?
>
>I considered that briefly, but make is bootstrapped early, so it
>is initially built with the host getopt(3). It seems unwise to run
>with known bugs for many reasons. How, for example, would you test
>it? ("Well, this test suite is for the make I built 3 minutes ago
>and this test suite is for the one I built 15 seconds ago, oh, and
>this test suite doesn't work unless run on host X99 ..."--for good
>material on testing see junit and "extreme programming" for some
>interesting philosophy.)
>
>Secondly, it still leaves the code depending on artifacts of the
>bsd getopt(3) implementation that aren't in posix and have been
>proven unportable. Groff isn't the only problem this has caused.
>
>The decision to allow intermixed X=Y assignments and command line
>options (itself, sigh, a posix extension, there is a lesson there
>somewhere) was made years ago in both pmake and gmake. I can't
>remove functionality from a release but I can deal with the
>requirement of make for portable extra-fancy argument parsing.
>
>If getopt(3) works for 199/200 programs and 0.5% of them need to
>be handcoded then I say mix metaphors, declare victory, and call
>it a day.
>
>Having said all that, I'm perfectly happy to withdraw it and check
>it into the Wasabi tree, rather than argue too much...

Well, I would leave it in. I would have preferred it if it was implemented
as a getopt() replacement, enabled #ifdef BOOTSTRAP and placed in util.c

That way, the code does not change in the normal environment, and it
uses the libc getopt() as intended.

christos