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