[Top][All Lists]

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

Re: bison --version (Was Re: Midnight Commander and bison 1.29)

From: Pavel Roskin
Subject: Re: bison --version (Was Re: Midnight Commander and bison 1.29)
Date: Mon, 10 Sep 2001 11:28:10 -0400 (EDT)

Hi, Akim!

First of all, let's remove address@hidden from cc:

Sorry for all that fuss.  FrИdИric reported a warning from "configure" for
GNU Midnight Commander, which showed that the bison version cannot be

checking for bison... bison
checking version of bison... v. ?.??, bad

FrИdИric did not investigate the problem, but instead asked in the mc-deel
list.  It turned out that the message comes from the macro AM_GNU_GETTEXT
(from gettext-0.10.39).  The comment in the macro says:

intl/plural.c is generated from intl/plural.y. It requires bison, because
plural.y uses bison specific features. It requires at least bison-1.26
because earlier versions generate a plural.c that doesn't compile.
bison is only needed for the maintainer (who touches plural.y). But in
order to avoid separate Makefiles or --enable-maintainer-mode, we put the
rule in general Makefile. Now, some people carelessly touch the files or
have a broken "make" program, hence the plural.c rule will sometimes fire.
To avoid an error, defines BISON to ":" if it is not present or too old.

So the idea of the test was to prevent old version of bison from
regenerating plural.c if something goes wrong with timestamps.

The test tries to parse the output of "bison --version":

ac_prog_version=`$INTLBISON --version 2>&1 |
    sed -n 's/^.*GNU Bison .* \([0-9]*\.[0-9.]*\).*$/\1/p'`

As you can see, the sed command wrongly assumes that there is a space
after "GNU Bison", which is not true for Bison 1.29.

I have reported the problem to the gettext maintainers, but haven't
received any answer so far.

Unfortunately, after I explained the problem to FrИdИric, he posted this
useless report to address@hidden  Sorry that I caused it, I'll be more
careful with FrИdИric next time :-(

> |I thought it was a --version change, but I removed 1.28
> |before configuring. Anyway, apparently GNU Bison is wrong
> |since the new output breaks the test. I'm Cc'ing bug-bison.
> |My fear is that it can break other projects that use it.
> |fetchmail ?

This is a pure speculation.  The only software that is affected is gettext
itself.  No user of other software using gettext should need to edit
plural.y, and therefore this is a non-issue.

Of course, one could argue why plural.y is distributed at all with the
projects using gettext, but this question has nothing to do with bison.

Another question is whether it's possible to get the version number
without parsing the output of "--version", or, better yet, how to ensure
that the particular file is only processed with the recent versions of the
software (i.e. something like AC_PREREQ is Autoconf).  I could not find
anything like that for bison (I looked in bison.texinfo for version 1.29).

To sum up, the bugreport is bogus, there is nothing wrong with the output
of "bison --version".

But you can consider this message as a feature request - something like
%bison_version command would be useful to ensure that older version of
bison, as well as parser generators other than bison, refuse to process a
certain file.

Pavel Roskin

reply via email to

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