Red Hat Bugzilla – Bug 55870
unnecessary incompatibility with automake <= 1.4
Last modified: 2007-04-18 12:38:06 EDT
automake 1.5 actually requires all programs that use it to ship their own depcomp file (something they couldn't do with automake <= 1.4), the usual workaround is to add ln -s /usr/share/automake/depcomp . right before calling automake in the specfile. This is an unnecessary step; if ./depcomp isn't found, automake should automatically fall back to using its own version thereof.
AFAIK, the correct way to add `depcomp' (and `missing', `mkinstalldirs'...) is `automake -a' (plus `--foreign' sometimes). IMO an explicit regeneration of the autotool-files is unnecessarily in most cases and only needed when Makefile.am or configure.ac were changed (unfortunately, rpm calls `libtoolize' in %configure, but this can be cured by a `%define __libtoolize true').
I tend to agree.
I'm aware of the -a switch, and I think it should be the default if depcomp isn't found. What I'd like to have is automake -a = rebuild all related files unconditionally automake -A = never rebuild related files (= current automake behavior) automake = Check if all files (depcomp etc.) are there, if so, go ahead as usual, else assume -a. This would fix almost all rpm --rebuild foo.src.rpm problems we've been seeing after the updates.
I do not know if it is worth to break backward-compatibility just to omit three characters in a .spec-file... IMO it is more an rpm-issue; when libtoolize'ing while %configure, the other autotool-files should be updated also. This could be reached by calling "autoreconf -i" somewhere in this macro. Calling `aclocal; autoheader; automake; autoconf' manually in each .spec-file would blow it up unnecessarily. Because autoconf changed its behavior also (e.g. it is naming binaries "i386-redhat-XXX" under some circumstances now) the %configure macro must be extended in future versions (adding `--program-prefix=' fixes the new naming) in any case. Bero: My experiences with new autotools have shown that changed '-a' behavior is the smallest problem; my favorite ones are: - standard-macros (especially these from libtool.m4) in acinclude.m4; some "standard" tools like kdevelop are infecting a lot of projects in this way - missing parenthesises; new autoconf is more strict in this manner, so `autoconf' will fail with mysterious messages (the TIFFReadScanLine-check in imlib is a good example) - `libtoolize' is not thorough enough; older `install-sh' scripts do not understand the `--run' argument required by newer libtool.m4 - bad coded m4 macros using autoconf/automake internals from former versions - the i386-redhat-XXX naming mentioned above Compiling Gnome/Ximian-packages without `%define __libtoolize true' is horridly; don't know if KDE is better...
Changing the -a behavior wouldn't break backwards compatibility, it would improve it. Running automake without -a will *never* produce something that works if depcomp isn't there, so it's sane to assume the caller wants to copy it over. I'm not so much concerned about adding 3 characters to spec files, I'm more concerned about Joe Random User trying to compile his own packages. Both KDE'ish Makefile.cvs files and GNOME'ish autogen.sh files usually call automake without the "-a", therefore the user will get a bunch of error messages rather than the expected configure script. I don't think there's a good reason *not* to change this. As for the libtoolize stuff, I agree it plain shouldn't be used, as there's no point in using libtool on a platform that can handle library dependencies and library versioning by itself, but unfortunately, that's not the road we've picked.
I am using 'automake -a' only a few times at the beginning of projects, but 'automake' (to rebuild Makefile.in) frequently. Imagine a '--foreign' project and an user who calls automake to regenerate Makefile.in's, but omits the '--foreign' flag inadvertently. The automatic '-a' would add INSTALL and COPYING files which may be inadequate for the project; the current version tells that there is something wrong. Therefore, I think that backward compatibility will be broken... Because automake is a developer tool, "Joe Random User" will never use it. Developers know their tools (this can be expected at least ;) ), so I do not see a reason to add automatisms which will shoot into your foot at small mistakes. To your comment regarding Gnome and KDE autogen scripts: IMO this way is too complicated and intransparently; an easier and standardized one would be the execution of 'autoreconf -i' (I know that rawhide version has some flaws).
Just a short compatability note: The development automake never runs libtoolize. Instead, the user is expected to use `autoreconf' for this task. Gnome, KDE, and other projects with autogen.sh would be well advised to move to using autoreconf (once they upgrade to sufficiently new auto* tools).