GNU bug report logs - #14775
automake 1.13.3 warning about version mismatch

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14775 in the body.
You can then email your comments to 14775 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Peter Johansson <trojkan <at> gmail.com>
To: bug-automake <at> gnu.org
Subject: automake 1.13.3 warning about version mismatch
Date: Wed, 03 Jul 2013 09:46:06 +1000

Hi,

This is probably already fixed with the version scheme and everything, 
but wanted to report it just in case. I updated from from automake 1.13 
to 1.13.3 and after having modified an Makefile.am, Automake complained 
about version mismatch. I suspect aclocal.m4 was created with aclocal 
1.13 (?). This is easily resolved by running autoreconf -if, but I found 
it odd that a patch upgrade should cause that minor head ache. 
Especially since I then upgraded to Automake 1.14 and expected the same 
thing to happen, but no - now if I issue 'make' it will happily keep 
running automake-1.13 (which is version 1.13.3 obviously). So in short 
upgrading a patch version cause version mishmash but upgrading a minor 
version is smoother than expected. Is this still the case with 1.14, 2.0 
etc? If so, is it on purpose?

Cheers,
Peter

Message #8 received at 14775 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 14775 <at> debbugs.gnu.org
Subject: Re: bug#14775: automake 1.13.3 warning about version mismatch
Date: Sun, 21 Jul 2013 20:19:56 +0100

tags 14775 notabug
close 14775
thanks

Hi Peter, sorry for the delay.

On 07/03/2013 12:46 AM, Peter Johansson wrote:
> Hi,
> 
> This is probably already fixed with the version scheme and everything,
>
Actually it's not...

> but wanted to report it just in case.
>
... so you did well.  Thanks.

> I updated from from automake 1.13 to 1.13.3 and after having
> modified an Makefile.am, Automake complained about version
> mismatch. I suspect aclocal.m4 was created with aclocal 1.13
> (?).
>
I think so, yes.

> This is easily resolved by running "autoreconf -if", but
> I found it odd that a patch upgrade should cause that minor
> head ache. Especially since I then upgraded to Automake 1.14
> and expected the same thing to happen, but no - now if I issue
> 'make' it will happily keep running automake-1.13 (which is
> version 1.13.3 obviously). So in short upgrading a patch
> version cause version mishmash but upgrading a minor version
> is smoother than expected. Is this still the case with 1.14,
> 2.0 etc?
>
Yes.

> If so, is it on purpose?
>
Basically yes.  Think about the following situation:

  1. A user has generated his Makefile.in with Automake 1.14.

  2. We release Automake 1.14.1, that contains a bug fix that
     involves changing some internal details in AM_INIT_AUTOMAKE.

  3. The user upgrades to Automake 1.14.1, without re-running
     autoreconf.

  4. Remember that the old (1.14) AM_INIT_AUTOMAKE definition has
     been copied by the the old aclocal 1.14 in the generated
     aclocal.m4, and it's still there, even after the Automake
     upgrade.

  4. The user modifies his Makefile.am, and re-run 'make'.

  5. automake 1.14.1 is run, expecting to be able to rely on
     the new version of the AM_INIT_AUTOMAKE internals.   But
     that expectation is *wrong*, since the AM_INIT_AUTOMAKE
     present in aclocal.m4 is still the one from Automake 1.14,
     and it is not going to be changed, since aclocal is not
     being re-run.

  6. Possible inconsistencies or spurious errors ensue.  Oops.

So I believe the current strict version checking is actually
necessary, albeit possibly a little annoying for the user.

Remember, the rule of thumb is the following:

  * Whenever you upgrade any component of the Auto* toolchain,
    re-run "autoreconf --force" -- even if it is just a micro
    version upgrade.

In the hope you'll agree with my reasoning above, I'm pre-emptively
closing the bug report.  If you don't agree, feel free to re-open
it and continue the discussion here (and of course feel free to
continue the discussion even if you do agree, but still have
something to add :-)

Thanks,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.