Re: AC_PROG_YACC

For future reference, FreeBSD 4.10-PRERELEASE and FreeBSD 5.2-RELEASE
still uses the following in /usr/share/mk/sys.mk which is the set of
defaults for '/usr/bin/make'

.if defined(%POSIX)
YFLAGS          ?=
.else
YFLAGS          ?=      -d
.endif

This idiom has been present going back to FreeBSD 2.2.6-RELEASE at
least.

Looking at NetBSD bmake sources, it seems that Darwin.sys.mk uses
'YFLAGS?=-d', Linux.sys.mk uses 'YFLAGS=-d' as does HP-UX.sys.mk,
OFS1.sys.mk, SunOS.4.sys.mk, SunOS.5.sys.mk while NetBSD and OpenBSD use
'YFLAGS?=' and so would not have a problem. Of course, this is only the
'portable' version of 'bmake 20040220' and earlier versions may not be
the same.

You should therefore ask yourself if it is wise to assume that getdate.h
is not going to be clobbered by a 'bison' run with these flags and avoid
it thru other hackery, or bow to expediency and possibly set it to what
you believe the default should be. Users may still override the value on
the make command line depending on how you choose to set it.

I will also note that the current getdate.y assumes that a bison 1.35 or
more recent is available. On many older systems, bison 1.25 is in use
and that version does not provide for a yyparse() that takes an argument.

So, you may wish to create a requirement for bison 1.35 or greater if
you wish to use a reentrant version of yyparse or otherwise hide things
so that on systems where yyparse takes no arguments, things will still
work properly.

	Enjoy!
	-- Mark

Derek Robert Price <[email protected]> writes:

> Bruno Haible wrote:
> 
> >Derek Robert Price wrote:
> >
> >>It appears that some `make's (notably some BSDs) have a default
> >>setting for YFLAGS (YFLAGS = -d) that some of my users are not happy
> >>with.  It breaks builds, notably with the GNULIB getdate package,
> >>which comes with its own getdate.h header (which gets overwritten by
> >>calls to `bison -y -d getdate.y'...).  Is this something that
> >>AC_PROG_YACC (or gl_BISON for the GNULIB folks) should be checking for
> >>and dealing with?
> >>
> >>My workaround will be to just stick a `YFLAGS=' line in my
> >>Makefile.am, but I thought you might like the bug report.
> >
> >
> >The automake documentation says:
> >  "When `yacc' is invoked, it is passed `YFLAGS' and `AM_YFLAGS'.  The
> >   former is a user variable and the latter is intended for the
> >   `Makefile.am' author."
> >
> >So this means, YFLAGS is meant as a variable through which the user can
> >influence the compilation (like CFLAGS, CPPFLAGS, LDFLAGS etc.). By
> >setting it to empty, you give the user less freedom.
> >
> >I'd say, since option '-d' is not appropriate in all cases, it's a
> mistake
> >to use it by default. The bug is therefore in the BSD make.
> 
> 
> I'm afraid I agree with you.  It might still make sense to have an
> autoconf workaround for the bug, when detected, however.
> 
> Derek
> 
> --
>                 *8^)
> 
> Email: [email protected]
> 
> Get CVS support at <http://ximbiot.com>!