[Top][All Lists]

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

Re: automake parallel install

From: Alexandre Duret-Lutz
Subject: Re: automake parallel install
Date: 13 Jan 2002 14:10:45 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7


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


 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

reply via email to

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