automake
[Top][All Lists]
Advanced

[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





reply via email to

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