autoconf
[Top][All Lists]
Advanced

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

Re: AC_PROG_YACC question


From: David Coquil
Subject: Re: AC_PROG_YACC question
Date: Mon, 8 Oct 2001 00:02:08 +0000
User-agent: Mutt/1.2.5i

On Sun, Oct 07, 2001 at 01:36:12PM -0600, Bob Proulx wrote:
> > >   AC_CHECK_PROGS(YACC,byacc yacc 'bison -y',[${am_missing_run} yacc])
> > 
> > Looks like a nice quick fix but this doesn't seem to work with autoconf 2.13
> > :-(.  The generated configure script reports that bison, byacc, yacc
> > are missing but happily goes on without any other warning.
> 
> Yes, but generally the generated y.tab.c et al one one system will
> work on another system.  Not always, but mostly.  Therefore the
> generated C files are distributed as well as the yacc and lex source
> files.  If you don't change the real source then the generated C
> source is still considered valid.  In that case even if you don't have
> yacc and lex on your machine you can still compile the program.  So
> not having it at configure time is not necessarily fatal.

Aaah OK, now I understand. I haven't used those beasts (lex/yacc) for a long
time and had forgotten about this feature. I came across this while
attempting to build a package ; the package doesn't distribute the generated
files, but instead attempts to build them at compile time. It's the package
that is broken, not the autoconf macro :) : either it really needs to use
yacc at compile time because of some yacc subtlety that makes the generated
files system-dependant, or it should just distribute the generated files. 

> If, however, you modify the real source then at the next make you will
> need to have the yacc or lex programs available on your system.  They
> were not found at configure time.  But who knows, you might have
> installed them by then.  The missing script will give it a shot.  If
> everything works then no harm no foul.  But if there is any error at
> all then the missing script will print the message then.
> 
> It would certainly be possible to fail with a fatal error in the
> configure script at configure time.  But normally most packages
> wouldn't need that.
> 
> I have been putting the generated C source into the MAINTAINERCLEAN
> variable list in Makefile.am files.  It seems appropriate to me that I
> can do a 'make maintainer-clean' at the top level and then 'bootstrap'
> myself completely from source on a different system than I originally
> built upon to test portability.

Makes sense, from what you tell me I now understand that yacc/lex are only
required for maintainers like, say... autoconf !!

> > I probably need to upgrade, as I have found no mention of
> > am_missing_run on the files owned by my current autoconf package,
> > whereas it is defined in m4/missing.m4 in autoconf 2.52.
> 
> I can't say as I found it in any documentation.  I pulled it out of
> other examples of its use in /usr/share/{aclocal,autoconf,automake}!
> It might not be a public interface!

Can't tell. What surprises me is that I haven't found it anywhere in the
files of my 2.13 binary package, but still autoconf doesn't complain about
it when it sees it :).

Thanks for the explanations anyway,

--
David Coquil



reply via email to

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