Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 55870 - unnecessary incompatibility with automake <= 1.4
unnecessary incompatibility with automake <= 1.4
Product: Red Hat Raw Hide
Classification: Retired
Component: automake (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Brian Brock
: FutureFeature
Depends On:
Blocks: 56081 56082 56083
  Show dependency treegraph
Reported: 2001-11-07 18:12 EST by Bernhard Rosenkraenzer
Modified: 2007-04-18 12:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-18 03:10:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bernhard Rosenkraenzer 2001-11-07 18:12:07 EST
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.
Comment 1 Enrico Scholz 2001-11-07 18:57:16 EST
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').
Comment 2 Jens Petersen 2001-11-12 01:59:25 EST
I tend to agree.
Comment 3 Bernhard Rosenkraenzer 2001-11-12 08:10:13 EST
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.
Comment 4 Enrico Scholz 2001-11-12 13:45:30 EST
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...
Comment 5 Bernhard Rosenkraenzer 2001-11-12 14:47:53 EST
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 
Comment 6 Enrico Scholz 2001-11-15 20:57:33 EST
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).
Comment 7 Tom Tromey 2001-12-02 17:55:56 EST
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).

Note You need to log in before you can comment on or make changes to this bug.