This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: automake parallel install
Am Son, 2002-01-13 um 22.14 schrieb Tom Tromey:
> >>>>> "Tom" == Tom Tromey <tromey@redhat.com> 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