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