Re: Automake-installed auxiliary scripts can get silently out-of-date after an Automake upgrade

[Eric Blake]

[adding bug-m4]

On 06/26/2012 05:23 AM, Stefano Lattarini wrote:

>>> I'm almost inclined not to do so, to force the affected
>>> projects' broken setup to be fixed; i.e., if you are using Automake 1.11,
>>> you let it install the correct 'missing' program, instead of forcing it
>>> to use the 'missing' from Automake 1.13.
>>
>> But developers don't have the impression that they are doing something
>> wrong when they use an old 'missing' program.

In fact, this is how GNU M4 got into this predicament in the first
place.  Since I noticed with GNU M4 that 'missing' wasn't automatically
updated when moving to a newer automake, I made the change months ago to
have GNU M4 pick up the latest version of missing from gnulib rather
than the version that shipped with the currently-installed automake; in
this way, GNU M4 did not need to rerun 'automake --force', when running
with a newer version of automake, but just automatically picked up the
new build of 'missing' - this worked up until this week's changes broke
backwards compatibility where a newer 'missing' was incompatible with an
older automake.  Maybe it's a bug in m4's bootstrap procedures for
relying on a symlink to the latest 'missing' from gnulib instead of
using 'automake --force --install' to install things, but I can't help
but wonder how many other packages might have similar issues.

>> No warning. How is a developer meant to notice that he's doing something
>> wrong if 'automake -Wall' does not tell him?
>>
> This is actually a good point.  When you upgrade your build system to
> a new Automake version, you should run automake with the "--force" option,

But if I'm relying on the automake shipped by my distro, then I'm at the
mercy of when the distro decides to upgrade to a new automake version.
It isn't obvious that just because some other tool was updated that I
now have to rerun with a --force option.

> to ensure that the automake-installed scripts are updated even if they
> are already present in the build tree.  But if you fail to do so, you
> don't get any warning, which is not very user-friendly and can cause such
> hard-to-spot errors.
> 
> Any idea for a simple solution to this problem?

Aren't there timestamps in the auxiliary scripts for a reason?  If a
script is updated as part of a new automake release, can't automake
insert some sanity checks to see if the currently-installed scripts have
too old of a timestamp, and complain about (or even better, auto-update)
those scripts that don't match the newer automake?  Either the build-aux
scripts are heavily tied to a specific automake version (and thus should
not be shipped as independent scripts mirrored in gnulib), or they are
independently useful (we should not be breaking features used by older
automake, and newer automake should be doing sanity checks that the
newer features are present before relying on the newer features).  I'm
not sure whether 'missing' is independently useful outside of automake;
maybe it is better to remove the mirroring of 'missing' in gnulib, and
to fix GNU M4 to use automake rather than gnulib for obtaining its copy
of 'missing' during bootstrap.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature