Re: calc.at workaround for current test failures

[Paul Eggert]

Paul Hilfinger <address@hidden> writes:

> this near-instantaneous adaptation of the latest version of support
> software is not standard practice.

Sorry about that.  Ironically this problem occurred because I was
responding to Frank Heckenbach's request yesterday to cut a new Bison
test release, so that he wouldn't have to deal with software support
issues.

While generating the new test release (which is not done yet) I ran
into the problem that gettext is extremely particular about its
versioning.  The gettext 0.12.1 manual says "It is highly recommended
that all developers on a project use the same version of GNU `gettext'
in the package."  I can vouch for this, having briefly endured the
problem of different developers using different gettext versions; it
doesn't work well at all.

In the short run I think we're sort of stuck: we can't easily
disentangle these version dependencies right away.  However, in the
long run it would be nice to fix this.


> Generally, an individual project should build with N-year-old
> versions of all relevant support software (or later versions, of
> course).

Currently Bison assumes the latest stable version of all GNU developer
tools.  Different developers use different GNU distributions, and we
can't and shouldn't rely on everybody using Red Hat 9.0 or Debian
GNU/Linux 3.0r1 or whatever.  Under the current regime it's therefore
the developer's responsibility to install the latest GNU developer
tools themselves.

Keeping Bison portable to older releases of the developer tools would
cost some Bison-developer time, also somebody would have to volunteer
to do the ports, and to maintain them.  So far we've been assuming
that the cost of maintaining older ports would exceed the cost of
having developers all stay up-to-date.  Perhaps this assumption is
incorrect.

Personally, I keep up-to-date, partly because I help with other
packages like coreutils that require bleeding-edge developer tools.
I do this by having makefiles that look like this, one for each
developer package:

   PROGRAM = automake
   VERSION = 1.7.5

   include ../_generic/config.mk
   include ../_generic/configure.mk

and when a new version comes out, I update VERSION, type "make
install", and I'm done.  Perhaps this sort of procedure should be
written up somewhere?  That might be less work than trying to port
Bison to older developer tools.