[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
- AC_PROG_YACC question, David Coquil, 2001/10/05
- Re: AC_PROG_YACC question, Bob Proulx, 2001/10/05
- Re: AC_PROG_YACC question, David Coquil, 2001/10/07
- Re: AC_PROG_YACC question, Bob Proulx, 2001/10/07
- Re: AC_PROG_YACC question,
David Coquil <=
- Re: AC_PROG_YACC question, Bob Proulx, 2001/10/07
- Re: AC_PROG_YACC question, Tim Van Holder, 2001/10/08
- Re: AC_PROG_YACC question, David Coquil, 2001/10/08
- Re: AC_PROG_YACC question, Tim Van Holder, 2001/10/08
- Re: AC_PROG_YACC question, Bob Proulx, 2001/10/09
- Re: AC_PROG_YACC question, Akim Demaille, 2001/10/10
- Re: AC_PROG_YACC question, Akim Demaille, 2001/10/10