Re: automake parallel install

[Ralf Corsepius]

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.

Example: 
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
automake.

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

Ralf