bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC h


From: Andreas Gruenbacher
Subject: Re: [PATCH 4/4] Use AM_MISSING_PROG when making bison the default YACC here
Date: Wed, 28 Apr 2010 00:40:43 +0200
User-agent: KMail/1.12.2 (Linux/2.6.31.12-0.1-desktop; KDE/4.3.1; x86_64; ; )

On Wednesday 28 April 2010 00:15:59 Bruno Haible wrote:
> Hi Andreas,
> 
> > * m4/bison.m4 (gl_BISON): We need to use AM_MISSING_PROG for making
> > bison the default YACC or else packages cannot be built without bison.
> >    # getdate.y works with bison only.
> > -  : ${YACC='bison -y'}
> 
> Can you explain what is the problem with YACC='bison -y'?

The problem is that in the generated Makefile, you end up with:

        YACC = bison -y

instead of:

        YACC = ${SHELL} .../missing --run bison -y

> This variable will not be used if a user unpacks and compiles a virgin
> tarball.

... unless the timestamps get destroyed, or make gets things wrong.  The 
latter apparently happened to Daniel (CCed) on Tru64 with the native make; the 
result was a build failure.  (GNU make got that situation right.)

> Using 'missing' makes the compilation less reliable in the case that
> the user has fiddled with the .y file and does not have bison on his
>  machine. With YACC='bison -y', the compilation will abort, and the user
>  will be forced to fix the situation in a reasonable way.

This argument applies against the missing script generally -- it's inherently 
unsafe, it only helps users build packages in weird situations.  I guess we 
all know missing is a hack.

> With YACC='missing bison -y', the missing script will create dummy files
> instead of running bison, which will lead to breakage later.

It may end up using the shipped version of the bison-generated file, not 
random dummy files.

> The warning that it emits at that moment is likely to be overlooked in a
> long compilation log.

When someone modifies the .y file, he is much more likely to notice either the 
warning in the log, or figure out that the change did not have the desired 
effect during testing, no?

> Besides that, I object to the use of the AM_MISSING_PROG macro because it
> is undocumented and can therefore be changed without notice.

Hmm, what could be used as a replacement?

Thanks,
Andreas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]