Re: automake parallel install

[Alexandre Duret-Lutz]

[...]

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

This seems to be the minimum required to allow parallel installs
of Automake.  However doing only this makes unsafe to use
versions installed that way, due to the rebuild rules issue you
pointed out: using automake-1.5 is useless if the resulting
Makefile.in's only call automake.

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

 Havoc> The version that gets encoded in file and directory
 Havoc> names should be like a soname; it changes when you break
 Havoc> the "ABI"

Maybe `automake' should not be a symlink but a script that
select the right automake version to use for a project.  I'm
very sceptic about all this, tho.

It's easy to write Makefile.am's that works with both Automake
1.4 and 1.5.  If some project requires 1.5 it can require it
using the '1.5' option.  Ideally, Automake 1.5 users should to
be able to compile every project.  Maybe it would be better to
focus on ensuring backward compatibility, rather than devising
something which will hide unwanted ABI breakage.

[...]

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

(Aside: Maybe address@hidden@_la_LDFLAGS does?)

[...]

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

easily

 Havoc> It's probably appropriate to simply make a decision on
 Havoc> whether third-party macros can be "for any automake"

I think Tom was thinking about Automake's own macros.

 Havoc> or whether they have to be for a specific automake
 Havoc> "ABI".

I don't think such dependency exists.  Third-party m4 macros are
usually dependent upon Autoconf, not Automake.  I'm sure Akim
will write "aclocal should belong to Autoconf" if he posts a
message in that thread <wink>.

[...]
-- 
Alexandre Duret-Lutz