[Top][All Lists]

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

Re: automake parallel install

From: Havoc Pennington
Subject: Re: automake parallel install
Date: 11 Jan 2002 11:29:45 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Ralf Corsepius <address@hidden> writes:
> This would require to change all packages providing aclocal/ macros of
> their own, i.e. is not feasible at present time, IMHO.

It can be done slowly if you continue to search datadir/aclocal for
now, and also search the versioned directories. Just deprecate
datadir/aclocal if the decision is that macros must be for a specific
> 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

I don't see how this is avoidable.

Either a) m4 macros can be written which work with all autotools, in
which case you can use any automake with gtk.m4 or b) m4 macros are
autotool-version-specific, in which case packages must use only
autotools that gtk.m4 explicitly supports.

The problem with a) is that it requires seeing the future, or locking
down the "ABI" of autotools. The problem with b) is that sometimes it
happens that a new autotools version does work with an old macro, even
though it isn't really the policy of either GTK or autotools that it
should, and people want to take advantage of this accident.

I can imagine autotools looking for an "old" macro if a new one isn't
found, perhaps, which would let people use the
accidental-compatibility. Or maybe packages should always install
their latest m4 to datadir/aclocal in addition to the versioned
locations, in the hope that new autotools will be able to use it.
I don't know.

The strong opinion I have here is that it's broken to rely on a)
without actually guaranteeing that a) is going to work. i.e.  you
can't just have one datadir/aclocal but no fixed definition of what
kind of macros are in there. It's important to define a policy.

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

That's a separate issue from patching automake. (As an aside, fixing
for autoconf 2.5x has been much simpler than fixing for automake 1.5,
for whatever reason. The only thing it seems to require so far is
adding extra [] quotes in certain places.)

> > 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 in the control of someone who can fix things.  It's not
automake's job to fix other packages; it's automake's job to provide a
mechanism and policy whereby other packages have a Right Thing they
can do.

Sharing datadir/aclocal between all packages means the Right Thing is
for all packages on a system to use the same version of automake; and
that truly is something out of the control of any individual
maintainer, which I think is holding up automake 1.5 adoption.

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

Right, I did version share/automake - I should have mentioned that. 

You're right it may well make sense that if we say datadir/aclocal-1.4
is a location for third-party macros, that the automake-internal
macros should not also go there.


reply via email to

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