[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: automake parallel install stuff
From: |
Ralf Corsepius |
Subject: |
Re: automake parallel install stuff |
Date: |
17 Jan 2002 05:50:48 +0100 |
Am Mit, 2002-01-16 um 18.06 schrieb Havoc Pennington:
>
> Jens Petersen <address@hidden> writes:
> > -m4datadir = $(datadir)/aclocal
> > +m4datadir = $(datadir)/address@hidden@
>
[..]
>
> So if the change is done this way, we need a commitment from the
> autoconf maintainers that share/aclocal macros will never break with
^^^^^^^^ ^^^^^^^^^^^^^
autoconf automake!
> new autoconf, which I think is a silly commitment to expect, ergo I
> would personally go with putting the interface version (just the
> "1.4") in share/aclocal-1.4 and encouraging third party macros to go
> in there. Or perhaps it's more appropriate to use an autoconf version
> in the name e.g. share/aclocal-2.5x or something.
1. IMO, using the autoconf's version number would be appropriate,
because third-party share/aclocal/+.m4s are configure-script fragments,
therefore are subject to autoconf compatibility and only marginally
related to automake at all.
2. I am not sure if recommending share/aclocal-<version> for third party
macros is a good idea:
* Currently hardly managable on the user-side => If at all, then some
auto*tool should installing *.m4's to share/aclocal-<version>
automatically (data_ACLOCALS = foo.m4 ??)
* share/aclocal macros can be (and currently are supposed to be)
compatible to several versions of auto*tools. Installing third party
macros to aclocal-<version> would unnecessarily tie these to a
particular set of autotools and raise further problems if later used
with other packages' configurations.
3. I would prefer to put automake's own macros (which are likely
sensitive to incompatibilities between different versions of automake)
into share/[automake|autoconf]-<version>/aclocal. This would completely
decouple third party and automake's aclocal*.m4s.
4. People should learn to apply autoupdate on share/aclocal/*.m4s.
> Anyhow, let's stop overcomplicating the problem. There are very few
> names that matter:
>
> datadir/aclocal-whatever
> bindir/aclocal-whatever
> bindir/automake-whatever
+ datadir/aclocal
> Just make them change when and only when they break. There's no rocket
> science involved, just details, but the available choices for the
> details should be clearly defined.
This stuff ain't as easy as you might think, believe me :)
Ralf