Re: Configuration/Makefile cleanups

[Marc Espie <espie at schutzenberger dot liafa dot jussieu dot fr>]

On Fri, Nov 24, 2000 at 03:57:35PM +0100, Gerald Pfeifer wrote:
> On Fri, 24 Nov 2000, Marc Espie wrote:
> > [byacc vs bison]
> > It is not encumbered with the GPL license.
> 
> Please, let's keep politics from this list.  My primary goal (at least)
> is helping to develop a free compiler that is as good as possible for as
> broad a user base as possible, and I don't think anyone here will
> disagree.

Well, I quite agree to keep politics from this list, as long as it works
both ways (e.g., using bison-only is heavily political).  The point I want  
to make is that there is no *technical* reason to prefer bison except 
for java, and so it will be perceived as a *political* choice, one 
the BSDers blatantly disagree with.

> are trivial, but what should be the behavior, that is, which "YACC"
> should be used for which parser or how should configure behave, in
> your opinion, if

>  o both yacc (byacc) and bison are present and Java should not be built?
>  o both yacc (byacc) and bison are present and Java should be built?
>  o only yacc (byacc) is present and Java should be built?
> 
> And, how does the current behavior differ?

The default is not important. What's important is that it can be
configured. You can e.g., have the following behavior:
./configure -> use bison
>  o both yacc (byacc) and bison are present and Java should not be built?
bison
>  o both yacc (byacc) and bison are present and Java should be built?
bison
>  o only yacc (byacc) is present and Java should be built?
error


./configure --prefer-byacc
>  o both yacc (byacc) and bison are present and Java should not be built?
build with byacc
>  o both yacc (byacc) and bison are present and Java should be built?
java is built with bison, the rest with byacc.
>  o only yacc (byacc) is present and Java should be built?
error.

The only finesse is the case in which some synchronization is needed: it is
obvious that if any parser needs bison, and other parsers must be
synchronized with it, bison is needed. BUT this is not even the current
case, as the parsers that need to be kept synchronized can both be built
with byacc.

Note that we're talking about a distclean situation. I have absolutely no
qualm in having tools on my box that permit me to feed back patches to the
FSF folks, including the autoconf that uses gnu-m4 (yes, my autoconf does
NOT use gnu-m4), or bison to send back parser patches.

However, if the system includes some tools, then it seems reasonable to use
them, and not depend on extra software that does exactly the same thing.

In a similar way, I haven't looked closely at the way zlib is currently
built (I'm a little behind, somewhere around november 1st---likely not to 
be relevant for now, unless java makes it to 3.0).  There are a lot of systems
out there that do include zlib in the system libraries, and this is
screaming for a --with-system-zlib   configure knob, especially since
zlib IS the vintage zlib library.