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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature