Re: automake parallel install

[Tom Tromey]

>>>>> "Havoc" == Havoc Pennington <address@hidden> writes:

Havoc> I'm wondering if we could convince you and the autoconf guys to
Havoc> think about making incompatible autotools releases install in
Havoc> parallel.

I think this idea makes sense.  It does seem apparent that we need to
let people install some 1.4 and some 1.5 at the same time, due to the
many incompatibilities.  I personally reset PATH depending on what I'm
working on, but that would be painful for projects that use a mix.

Havoc> Also, in the spec file I rename automake to automake-1.4,
Havoc> aclocal to aclocal-1.4, automake to automake-1.5, aclocal to
Havoc> aclocal-1.5, and symlink automake to automake-1.5. I provide
Havoc> versioned executables in both RPMs because those are probably
Havoc> the best ones for other packages to refer to - so the packages
Havoc> won't need to be changed when automake-1.6 appears and gets the
Havoc> "automake" symlink.

What do you mean by "versioned executables"?

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?

Havoc> People seem to have an aesthetic reaction against including the
Havoc> version number in the name of everything at first

I guess I'm included in this category.  I'm willing to be convinced
though.

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.

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

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.


We're planning to do a prerelease soon, followed shortly by 1.6.  I'd
like to get this resolved before then, assuming the above issues (and
any more we think of) are tractable.

Tom