[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: automake parallel install

From: Havoc Pennington
Subject: Re: automake parallel install
Date: 11 Jan 2002 00:55:38 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1


Tom Tromey <address@hidden> writes: 
> What do you mean by "versioned executables"?

The bindir/automake-1.4, bindir/automake-1.5 files.
> I think renaming the directories in $(datadir) is fine.  But I'm not
> as sure about renaming the executables by default.  I think I'd prefer
> to simply install as `automake', and let package maintainers use
> `--program-suffix=-1.5' (or equivalent) in their spec files.  What do
> you think of that? 

The problem is that people are unwilling to make their upstream
packages depend on distribution-specific changes. (And some people
compile from tarballs of course.) I think there's less confusion if
all distributions plus tarballs result in the same setup.

The "automake" and "aclocal" symlinks remain for typing on the command
line, when you want the "default" autotools.

There's some value to allowing people to specify the expected version
of automake; typically they would do this in one place in their
package, and then they could ensure the right one is used. For example
in GTK we only support 1.4, and when we move to 1.5 we'll only support
1.5, and so having "automake" in our isn't really right -
"automake-1.4" would be a better executable name to use.

If we have "automake" there and it's unpredictable which version that
is, it just confuses everyone and results in people mailing the list
asking what's wrong when they get compile problems.

If we have "automake-1.4" in there and someone has the wrong automake
it will die in a way that has an obvious solution which is perfect.
--program-suffix works, of course, it just suffers from "most people
won't figure it out" I guess. Suitable release notes could help with

> One issue is what we put in the rebuild rules in the Makefile.  We'd
> have to put the version there.  That's a potential problem if, say,
> you move from using 1.5 to 1.5.1.  You'd have to re-run automake by
> hand, and your package would depend on the precise release.

The version that gets encoded in file and directory names should be
like a soname; it changes when you break the "ABI", not on every
release. So for example all GTK 2.0.x releases will use the same
datadir/gtk-2.0 directory for noarch data, we won't have
datadir/gtk-2.0.3. This is why my patch doesn't use @VERSION@ in the
names of things (IIRC, maybe I screwed it up).

For some of my packages I have AC_SUBST(MAJOR_VERSION) for this "ABI
version" concept. It does have to be hardcoded in some contexts though:
 libgconf_2_la_LDFLAGS = -version-info 

libgconf_$(MAJOR_VERSION)_la_LDFLAGS obviously doesn't work.

> I think the rebuild rule problem is even worse if autoconf is
> versioned.  Where will the version info come from?

I'm not familiar with the relation between the various autotools and
their versions (i.e. what is compatible with what or how the releases
are coordinated). Clearly some thought to autoconf interaction is
needed but I don't have anything intelligent to say about it.

> A problem with having aclocal look in $(datadir)/aclocal by default is
> that we'll end up picking up 1.4 macros for a 1.5 install.  I guess
> proper ordering of the `push's will handle this.

It's probably appropriate to simply make a decision on whether
third-party macros can be "for any automake" or whether they have to
be for a specific automake "ABI". If the latter, it makes sense to me
to deprecate datadir/aclocal as the install location and instead
encourage third parties to install separate .m4 files to both
aclocal-1.4 and aclocal-1.5, i.e. to the directories for all automake
versions they explicitly support. (See my other response to this
thread today, which isn't in the archives yet, so is maybe in limbo

Maybe it's right to try version-specific first then fall back to
datadir/aclocal - maybe I have this backward in my patch.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]