[Top][All Lists]

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

Re: automake parallel install

From: Ralf Corsepius
Subject: Re: automake parallel install
Date: 11 Jan 2002 11:30:00 +0100

Am Fre, 2002-01-11 um 03.52 schrieb Havoc Pennington:
> Ralf Corsepius <address@hidden> writes: 
> > => IMO, this patch is one alternative towards allowing parallel
> > installation of _automake_, but does not help much wrt. the actual
> > autotool-issues "Joe Occasional Installer" will meet (eg. when building 
> > GNOME modules).
> > 
> I agree there are other issues there, but the implication to me is
> that we have to address those other tools as well as automake. We
> still do have to address automake however. One step at a time.
Not the worst approach ;)

> It's true that share/aclocal is not versioned and this creates
> problems if third-party macros are dependent on specific versions. A
> semi-solution here is for third-party macros to start using the
> versioned share/aclocal-1.x directories instead.
This would require to change all packages providing aclocal/ macros of
their own, i.e. is not feasible at present time, IMHO.

Furthermore it would render these macros not to be applicable for other
packages which apply such macros.

If gtk.m4 was installed to share/aclocal-1.4, all packages applying
gtk.m4 were coupled to automake-1.4. 
If gtk.m4 is automake-1.4 and automake-1.5-compatible, and gtk.m4 can be
applied with automake-1.4 and automake-1.5

> However leaving
> share/aclocal in the search path works pretty well for now since most
> third-party m4 seems to work with both automakes.
Right, here the problem is _autoconf_ and I don't see any way around
fixing these macros.

[Many gnome macros are not autoconf-2.5x compatible => I don't see any
alternative to fixing them.]

> Something like GTK would probably install m4 to several different
> share/aclocal-1.x directories, to avoid imposing a specific automake
> version on programs using GTK. 
IMO, this can't work, because installing third-party macros is subject
of a package's configuration and currently is out of control of

> It's annoying there that if an app
> wants to upgrade automake they have to wait for a GTK release that
> supports the new automake, but I see no way around that short of a
> guarantee of back compat on the part of auto*.
Having thought further about your proposal, am inclined to think that
versioning share/automake is also required and that, if share/automake
was versioned, putting automake's own m4-macros to somewhere therein
would probably be better.


reply via email to

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