Re: parallel-tests

[Stefano Lattarini]

On 11/11/2012 02:16 AM, Karl Berry wrote:
>     "automake --add-missing" should install it for you automatically.
> 
> I didn't try it, but I don't doubt that much.
> 
> My question is, what is going to keep it up to date when (say) 1.12.5 is
> released with some bug fix for test-driver?  --add-missing doesn't
> update files as far as I can see (not that I'd expect it to, given its
> name), and automake -f didn't do it either.
>
"automake -a -f" should update all the Automke-provided auxiliary files.
After updating any of Autotools, you should run "autoreconf -fi", which
should automatically take care of any such "forced update" for you.

Or, you can avoid such issues at the root by stopping to commit any file
generated or installed by the autotools in Texinfo's CVS repo.  Most GNU
packages takes such an approach today, and live happily.

> That is, I changed the
> scriptversion= line to an old date and ran automake -f and it did not
> get updated.
>
The "scriptversion=" is there for human consumption only.  Automake
doesn't look at the content of the auxiliary scripts in any way to
decide where to update them -- the algorithm do decide which files
to update is much simpler:

  - if the "-a" option is *not* given, Automake won't try to install
    or update any file; if a required file it missing, Automake will
    complain and die.

  - if the "-a" option is given, but the "-f" option is *not*, Automake
    will install required files that are missing, but won't touch
    required files that are already present, whatever their timestap
    or content is.

  - if the "-a" and "-f" options are both given, Automake will install
    required files that are missing, and *unconditionally* re-install,
    from its own copy, required files that are already present.

> Furthermore, I would be very leery of updating things from
> the latest automake release because, very often, gnulib is going
> to have a newer version.  Ugh.
>
Yeah, using the 'test-driver' that comes with (say) Automake 1.13 in
Makefile recipes generated by (say) Automake 1.12 might not be such
a great idea ...  The right thing to do IMHO is to let Automake
always provide its own version of such auxiliary files, unless there
is a compelling way not to do so (and I don't see any here).

> If your answer is that the default is to use symlinks and therefore the
> update with a new automake release "just happens", well, 1) there is
> still automake 1.13 to be considered, when the symlink target would
> change to .../share/automake-1.13/, and 2) I prefer (need to use)
> copies.
>
Whether symlinks or copies are used is indeed irrelevant for our
discussion; using them instead of hard copies wouldn't help you in
any way (as you've correctly noticed).

> This general problem of keeping common files updated is why I invented
> the little srclist mechanism many years ago.  However, because the
> target file embeds a version number there is no future-proof way to make
> that work either.  That's where my suggestion of gnulib came in (so no
> version number would be involved), though I certainly recognize that is
> no easy panacea, and am not pushing for it.
> 
> Anyway, all a long-winded reply on such a tiny matter.  Sorry.  I guess
> the simplest answer is to add something to my checklist for making a
> release and/or automake-update.  Not the end of the world.
>
Or better again, IMVHO, just drop autotools-generated and -provided
files from the CVS repository.

HTH,
  Stefano