So yesterday I found out of the libtool 2.4 problems and today I spent quite a bit of time working on fixing the situation, and planning on how to avoid this to ever happen again. I think at this point, the only thing we can do is start getting rid of the oldest automake versions altogether.
This is easier said than done; while we can probably safely decide that any pre-1.9 version of automake (that is, all those that don’t work with libtool 2.4) can be considered dead and has to be moved away from, doing so on a regular basis is going to be troublesome: when we decide that an automake version is too far gone? When libtool stops working? When Perl stops working? When autoconf stops working?
But let’s start on why this is happening, or rather why is autotools.eclass allowing to choose a different automake version at all? The answer is mine to give most likely, given I am the original designer and implementer of the eclass.
When I designed it, I designed it to have three alternative interfaces: eautoconf, eautoreconf and eautomake. These three were supposed to cover all the use cases for autotools in ebuilds, trying not to do too much, nor too little — complications like intltoolize, gettextize and phpize actually escaped me at the time.
- eautoreconf is the common take-it-all approach: it rebuilds all autotools from scratch, calling aclocal, libtool (if needed), automake and so on; this is the default approach you should take if you’re uncertain about what you have to do;
- eautoconf is designed to be used only when there is no
Makefile.amfile, and thus automake need not to run; if you’re going to rebuildconfigurefor a package that does use automake, you shouldn’t use this at all; on the other hand, it doesn’t enforceWANT_AUTOMAKE=nonesince you can use aclocal (part of automake) without automake (see my documentation on the matter); - finally, eautomake was designed to optimise autotools rebuild: rather than rebuild all the chain, this was supposed to only call automake, as long as the current build system was built with the same exact version, and was to be used when only
Makefile.amwas modified, so thatconfigurewould be left untouched; since you’re supposed to use the same version, here’s whereWANT_AUTOMAKEwas really necessary.
Unfortunately, even though eautomake is much faster, its limitations nowadays make me think it was an horrible idea to implement it at all. First of all, it’s often misused: as I said it works only as long as the version used to build the patched build system is the same as the automake it’s going to use locally; this means that if you just leave WANT_AUTOMAKE to the default (latest) or set a different value than what the original package was built with, then it’s going to behave just like eautoreconf (indeed, as soon as it finds different automake versions it’ll scream treason and proceed to a full-rebuild); but even when used properly, there is not enough micro-version compatibility, so a build system built with automake 1.9.2 will require a full-rebuild anyway, given that our latest 1.9 supported version is 1.9.6.
Also, this automatic/automagic default of re-building all the autotools when the situation is unsafe, also causes a major problem: given that on a micro version bump of automake we move from building automake only to a full-rebuild, such a micro bump can cause problems to appear with newer libtool or autoconf packages just the same. And since I don’t usually go around testing on micro bumps, it’s more likely to create hidden problems.
Given all this, I’m actually considering asking to mark eautomake as deprecated, start removing its use from the tree, and add a QA warning to stop using it as soon as possible. Of course this won’t mean that WANT_AUTOMAKE will go away just yet; there are some cases where actually supporting newer automake is more work than it’s worth, but luckily such changes right now seem to be limited in the 1.9→1.10 bump, which is why I decided to set the lower bound at that version rather than sticking with 1.10⁄1.11 which are the newest. But even so, removing the whole idea of eautomake should reduce the trouble to maintainable levels.
At any rate, whatever the outcome will be, I’m pretty sure I’ll be handling most of the porting myself, but at least I hope to be able to write any particularly confusing situation in Autotools Mythbuster — after all, I’m doing it to help others, am I not?