Re: automake parallel install

[Ralf Corsepius]

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

> 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
version).
- 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
above. 
* 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.

Ralf