Bug 55870 - unnecessary incompatibility with automake <= 1.4
Summary: unnecessary incompatibility with automake <= 1.4
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: automake
Version: 1.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: 56081 56082 56083
TreeView+ depends on / blocked
 
Reported: 2001-11-07 23:12 UTC by Bernhard Rosenkraenzer
Modified: 2007-04-18 16:38 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-12-18 08:10:09 UTC
Embargoed:


Attachments (Terms of Use)

Description Bernhard Rosenkraenzer 2001-11-07 23:12:07 UTC
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 23:57:16 UTC
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 06:59:25 UTC
I tend to agree.

Comment 3 Bernhard Rosenkraenzer 2001-11-12 13:10:13 UTC
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 18:45:30 UTC
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 19:47:53 UTC
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.


Comment 6 Enrico Scholz 2001-11-16 01:57:33 UTC
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 22:55:56 UTC
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.