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
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
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
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
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).