Re: libtool 2.4: questionable advice

[Gary V. Vaughan]

On 5 Oct 2010, at 11:36, Ralf Wildenhues wrote:
>> Someday we'll finally throw
>> aclocal away, and let autoconf collect it's own macros I hope, and then this
>> problem will be gone for good.
> 
> Hmm.

It has long been acknowledged that aclocal is a kludge to work-around
the fact that there is no way to prepend directories into m4's search
path.  M4-2.0 already has this feature, as requested by Akim in order
that Autoconf can programatically set it's own search path, and then
collect all the macro's it needs without aclocal or aclocal.m4.

When M4-2.0 has propogated, and autoconf can look for the macros it
needs by itself, what is the point of aclocal?  (I know that aclocal
has acquired the feature of copying installed macros into the source
tree for distribution since Akim and I discussed removing aclocal
many years ago... but autoconf already shares perl infrastructure
with Automake, so I still think moving aclocal functionality into
Autoconf is a worthwhile simplification).

>> Libtoolize tries to be smart about checking both AC_CONFIG_MACRO_DIR
>> *and* ACLOCAL_AMFLAGS, and will flag an error if they give conflicting
>> macro dirs.
> 
> But giving wrong advice is never smart.  There are valid, legitimate
> setups where you want ACLOCAL_AMFLAGS to contain more than one macro
> directory.  There should be a way to shut libtoolize up.

Agreed.  I'll propose a patch later this month or early next if no-
one beats me to it.

Cheers,
-- 
Gary V. Vaughan (address@hidden)

PGP.sig
Description: This is a digitally signed message part