Re: AC_PROG_YACC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Paul,

Paul Eggert <[email protected]> writes:

> Bruno Haible <[email protected]> writes:
> 
> >   YACC="$GL_BISON -y"
> 
> The rest looks OK I guess, but this overrides any YACC
> settings imported from the environment or from explicit
> args, whereas the Autoconf tradition is to obey such
> settings.

True. However, if getdate.y were actually something that can
use 'yacc' or 'byacc' for YACC as defined by the system or
the user, then all of the issues recently raised become
somewhat moot as well.

That said, to the best of my understanding the most recent
GNULIB getdate.y seems to require features available only in
bison version 1.26 or better. If I am mistaken, please
correct me.

So, letting the user have much control over YACC at all is
going to cause problems due to the requirements for using
bison instead of a generic yacc.

Perhaps in this case of a bison-only .y file, the rules to
build getdate.c should use a BISON="${GL_BISON} -y" with an
explicit set of BISON-related Makefile variables? Something
like:

BISON = ${SHELL} ${top_srcdir}/missing --run bison -y
BISONCOMPILE = $(BISON) $(BISONFLAGS) $(AM_BISONFLAGS)
...
getdate.c: getdate.y
	$(SHELL) $(YLWRAP) `test -f '$<' || echo '$(srcdir)/'`$< y.tab.c $@ y.tab.h $*.h y.output $*.output -- $(BISONCOMPILE)

so that if there is a mixture of .y files with potentially
different feature requirements in a given project, they
will not run into the problem of needing an explicit version
of bison for one part and something else for another part...

Of course, maybe I have misunderstood the goals behind how
the GNULIB project is evolving?

> But I'm still confused as to why any of this is needed.  

I hope that this e-mail message helps to explain some of my
concerns and addresses your questions.

> Maintainers are expected to have up-to-date tools. 

Agreed.

Of course, this CVS maintainer was not initially aware that
there was a particular version of bison that was required.

In the past, bison 1.25 was sufficient. (Or, in some cases,
the use of byacc which had some other benefits at times over
the use of bison.)

Nor was I aware that the use of a version of 'make' other
than 'GNU make' was required and yet, that does appear to be
the case being made here.

In the past, the various GNU projects have been doing much
better than most other software projects at generating very
portable software configuraiton frameworks that work with
both non-GNU tools as well as with GNU tools.

If this is not longer the case, then I can adapt. However,
I do find it a sad change of policy.

If it is required that we maintainers only ever use GNU make
and bison and gcc on a GNU/Linux or GNU/Herd box, then that
would seem a reasonable goal. However, the cvs project is
attempting to continue to deliver cvs sources that will
build on most of the operating systems that are out there
and many that have not been updated in a very long time. It
does become a challenge and does require us to use versions
of 'make' other than GNU make and versions of $(CC) other
than gcc on occasion...

> If non-maintainers are invoking obsolete versions of
> maintainer tools, then they'll have other problems anyway.

This CVS maintainer is trying to work to ensure that our
documentation and configuration files always include
information on the minimum required tools and that the
templates provided by other projects like GNULIB will work
in as many environments as possible.

> We need to arrange things so that non-maintainers don't so
> often fall into the trap of invoking maintainer tools.

I totally agree. However, users do submit bug reports when
things do not work as expected. That a large number of
versions of 'make' are out there which pass a '-d' switch
via ${YFLAGS} exist should be understood. That this will
cause a problem with users of GNULIB in some circumstances
is a problem that we are attempting to address.

> Is the problem that people are getting sources directly
> out of CVS and building them, and that getdate.c is older
> than getdate.y? If so, then perhaps the simplest solution
> is to update getdate.c's time stamp.

The particular situation arose by a user doing a 'cvs
update' on their sources and getting the latest version of
getdate.y with a newer timestamp than the getdate.c and
having their BSD 'make' command corrupt the getdate.h file
by passing 'YFLAGS=-y -d' as a YACC command arguments.

While trying to reproduce the problem reported by a user of
the cvs sources, I used a FreeBSD system I had available, I
noticed that the version of 'bison' that configure found did
not work as getdate.y required and when using 'make' instead
of 'gmake' it created a version of getdate.h that was
unexpected.

Th requirement of a particular version of bison has already
been addressed by Bruno's recent suggested patch and I think
it would be well to make sure that the wrong version of
bison is not run by accident by any users or maintainers
along the way.

> If fixing CVS time stamps is not enough to fix the problem
> in practice, another possibility is to rename getdate.h to
> get-date.h.

I believe this suggestion has merit in the general case as
there is no guarentee that a user interested in
incorporating GNULIB into their project will necessarily
know that the '-d' switch is not desirable or is even
present.

> This would be a bit of a backward-compatibility hassle,
> but it would be quite a straightforward workaround to this
> FreeBSD compatibility glitch.

FreeBSD's /usr/bin/make is just one of the systems that have
this problem. Other versions of make that decended from
Berkeley's pmake (possibly some versions of OpenBSD) are
apparently also impacted in at least some releases.

FWIW: FreeBSD /usr/bin/make runs its shell actions using
'sh -e' which will cause problems with automake's check-TEST
due to it using 'sh -e' and the check rule using

    ...
    test -n "$$report" && echo "$$report" ; \
    ...

when $report is "", the test command will fail. The workaround
is to use

    ...
    test -n "$$report" && echo "$$report" || :; \
    ...

so that the statement does not error out.

I hope that I have addressed all of your questions.

Thanks for your continued improvement of the GNULIB sources.
	
Thank you for your understanding of our problem space.

	-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAmBYN3x41pRYZE/gRApiUAJ9e+NIDFj6GB2rYKF5lyX5AlrU24ACgk5OE
/dKupIVTEzvqsiowiTeiWec=
=nZ1s
-----END PGP SIGNATURE-----