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

[Eric Blake]

On 06/26/2012 12:04 PM, Bruno Haible wrote:
> Eric Blake wrote:
>>> 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
> 
> Yes, this is basically what I would expect "automake -Wall" to do.
> 
> But the timestamp is not the right thing to compare. There are lots of
> changes to the 'missing' file that did not make it backward incompatible.
> I would therefore do something similar as done in libtool [1]: Introduce
> a formal "invocation API stamp". It is a number (1, 2, 3, ...) with the
> property that if two versions of 'missing' have the same stamp they obey
> the same invocation conventions.
> 
> Then extend "automake -Wall" to compare the invocation API stamp of the
> copy in the current package with the invocation API stamp of the script
> that comes with libtool and emit a warning if they disagree.

Looking at automake.git/m4/missing.m4, the AM_MISSING_HAS_RUN macro is
almost there - it does an automake-time probe that 'missing' exists (via
AC_REQUIRE_AUX_FILE), then adds a configure-time probe that 'missing' is
new enough (that is, that 'missing --is-lightweight' succeeds).  Maybe
all that is needed is to hoist the check out of configure-time and into
automake-time by using m4_syscmd() to do the check during 'automake'.

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

signature.asc
Description: OpenPGP digital signature