[Top][All Lists]

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

Re: automake parallel install

From: Ralf Corsepius
Subject: Re: automake parallel install
Date: 14 Jan 2002 00:43:20 +0100

Am Son, 2002-01-13 um 22.14 schrieb Tom Tromey:
> >>>>> "Tom" == Tom Tromey <address@hidden> writes:
> Tom> But I'm not as sure about renaming the executables by default.  I
> Tom> think I'd prefer to simply install as `automake', and let package
> Tom> maintainers use `--program-suffix=-1.5' (or equivalent) in their
> Tom> spec files.  What do you think of that?
> Ok, now I'm convinced that we need to install the versioned
> executables.  It is the only way to get consistent results across all
> platforms using the default install behavior.
> Tom> One issue is what we put in the rebuild rules in the Makefile.
> My current thinking is that we would name the installed version and
> the install directories after the "install version".  For anything in
> the 1.5 series (1.5.1, 1.5-p1, 1.5c, whatever), this would be "1.5".
> Then we would guarantee that for a given "install version" we would
> only do bug fixes.
> So for instance you couldn't install 1.5 and 1.5.1 at the same time.
> You'd simply have to upgrade in this situation.
> My rationale for this is that often you can use a slightly older
> version.  So forcing everybody to upgrade to 1.5.2 or whatever, unless
> it is really required (something that can be specified in
> AUTOMAKE_OPTIONS), is a bit unfriendly.
Hmm, AFAIK, automake >= 1.5b requires autoconf >= 2.52, so such kind of 
situation probably will be inevitable once it will be released wrt. to

> Any comments on this?
> Tom> I think the rebuild rule problem is even worse if autoconf is
> Tom> versioned.  Where will the version info come from?
> Still no solution here :-(

May-be, I am going too far, but IMHO a drastic measure would help 
[I don't expect you to like this - This is just an ad-hoc thought
without having thought about all the details and consequences :)]:

1. Merge the autoconf and automake packages into one package. 
This would 
- guarantee version-consistency between autoconf and automake.
- solve the ownership problems (Does aclocal belong to autoconf? Is
aclocal being part of automake just a historical relic/accident?
IMHO, the answer to both is "yes")
- allow using on common pkgdatadir instead of several ones.

2. Implement a "common driver" to all autotools (Similar to gcc being
the driver to various other tools).
This would:
- Allow encapsulation of "autotools' components"
- Allow implementing an internal versioning mechanism (automake -V
- Ensure using a consistent set of "autotools' components" (Not bogusly
picking up the wrong version)

IMO, this would not be much different from what I'd consider a 
pragmatical approach: 
* Let autoconf be versioned similar to what is discussed for automake
* Let automake check for the version of autoconf, automake is being
configured with and hard-code this version into automake's files.

This would tie one installation of automake to exactly one version of
autoconf, without having the benefits merging automake and autoconf
would have.


reply via email to

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