automake-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automake-installed auxiliary scripts can get silently out-of-date af


From: Stefano Lattarini
Subject: Re: Automake-installed auxiliary scripts can get silently out-of-date after an Automake upgrade
Date: Tue, 26 Jun 2012 18:15:36 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]