GNOME Bugzilla – Bug 128691
Automake Check Broken
Last modified: 2004-12-22 21:47:04 UTC
The automake check in gnome-common/macros2/autogen.sh is slightly broken. It checks for different versions in the wrong order, only checks for automake-1.4 for the default requirement of 1.4, which breaks on machines that only have a newer version installed, and it doesn't check the unversioned automake script. This patch fixes the version check ordering, and adds the checks for newer versions to the 1.4 check, as well as adding just "automake" to all the version checks.
Created attachment 22158 [details] [review] Patch to Fix Automake Checks in gnome-common/macros2/
No. This is not a valid patch (the patch is fine, but it overlooks the reasoning why things are the way they are currently). Automake-1.5 and later are *not* completely backwards compatible with automake-1.4. There are a number of problems, although the main ones that bite are the requirements that all variables are defined before appending and the build must work with srcdir != builddir and srcdir being read-only (both of these requirements are for automake-1.5 and beyond). So if a package uses automake-1.4, unless it is very carefully designed to be fully portable (libxml being an example of one that is), it will not work properly with later automakes. For building from GNOME CVS, therefore, people need to have automake-1.4 and a later version (preferably 1.7) installed. This is not optional. Similarly, that is why we cannot just call 'automake', since there is no guarantee which version it is linked to (it is dependent upon the order in which the automake versions are installed). If somebody has automake-1.4 and a later version parallel installed, then calling 'automake' is a roulette spin and you may well end up with the wrong (incompatible) version. Go back to the archives of desktop-devel-list from the months leading up to when Havoc changed all the 'automake' calls to 'automake-1.4' (when automake-1.4d was released, I think) and you'll see the arguments. Nothing has changed since then (since automake-1.4 is end-of-lifed). The ultimate solution is that all of GNOME needs to be ported to a recent automake version (1.7, say). It would be nice if the release team decreed this would be a showstopper bug for all packages for GNOME 2.8, say. However, we have not really pushed this enough (and they are not going to make that call on their own). Sorry Rodney. I know this sucks in a "pure" sense. But for pragmatic reasons, it needs to stay the way it is. People do not take enough care with their build files for this to work.
Reopening because WONTFIX != INVALID, and the bug is valid even if automake-1.4 has to mean automake-1.4 for gnome-common. The general version checking checks the versions in the wrong order. I'm attaching a new patch which fixes only this. I'll just create a symlink farm for now, because if something uses broken stuff in 1.4, and gnome-common, I'd rather just fix it than use 1.4.
Created attachment 22225 [details] [review] Revised Patch to Fix Version Check Ordering
The ordering patch obviously looks good. Feel free to commit it. As far as the other stuff goes, things can use automake-1.4 correctly (they are absolutely *not* broken w.r.t. 1.4) and still be broken with automake-1.5. This is what "not backwards and forward compatible" means. The automake maintainers made a decision here and we are stuck with it. Upgrading things to use automake versions later than 1.4 is a good idea, but it's not a bug that things use automake-1.4 and cannot use later versions and gnome-common has to handle that case, since it is a common scenario.
Committed the ordering patch last night, so I'll mark this Fixed for that.