On 06/26/2012 05:37 PM, Eric Blake wrote: > [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? > Hmm... I wouldn't consider this solution as "simple" honestly.
What about this: since the great majority of the packages out there do not seem to override nor patch the Automake-provided auxiliary scripts, we could just make automake always reinstall such scripts by default; and allow the users to mark scripts that are not to be reinstalled this way (maybe a new autoconf macro -- "AM_BUILD_AUX_FILES_LOCAL", or something similar buth with a better name). How does that sound? > Either the build-aux > scripts are heavily tied to a specific automake version > Most of them are, yes. And should be considered internal details. Such files are: - elisp-compile - py-compile - mdate-sh - missing - ylwrap - test-driver - tap-driver.sh - tap-driver.pl Other files are more generally useful, and thus less likely to undergo "gratuitous" backward incompatibilities: - ar-lib - compile - depcomp - install-sh - mkinstalldirs > (and thus should not be shipped as independent scripts mirrored in gnulib), > In fact, I cannot understand why files like 'ylwrap' and 'missing' (only useful to implement some automake internals) are being 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. > Yes please! If we need a genuinely generic and stable script that offers some of the features of 'missing', it should be implemented in gnulib -- then, if possible, it will be automake which will start syncing it from the gnulib repo. Thanks, Stefano