Re: libtool 2.4: questionable advice

[Gary V. Vaughan]

Hi Bruno,

On 5 Oct 2010, at 07:11, Bruno Haible wrote:
> Can someone explain to me this advice from libtool 2.4? It says
> 
>  libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.ac and
>  libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
> 
> although my package already has a macro dir != m4.

When I added that warning to libtoolize, some tools took their cue for macrodir
from AC_LOCAL_AMFLAGS and some from AC_CONFIG_MACRO_DIR.  I don't remember
the precise split, and I never really understood why aclocal added a new
way of declaring the macrodir in Makefile.am.  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.

>  * Why is it telling me to put _another_ macro dir into configure.ac?
>    In other words, why does it not recommend to add
>      AC_CONFIG_MACRO_DIR([glm4])
>    ?

That is a bug, thanks for spotting it.  I've added fixing it to my TODO.

>  * Why is it telling me to use AC_CONFIG_MACRO_DIR at all? Since it
>    has already determined that 'glm4' is my local macro dir (presumably
>    by analyzing the ACLOCAL_AMFLAGS in Makefile.am), what would be the
>    point of declaring it a second time, through AC_CONFIG_MACRO_DIR ?

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.  Actually, if you follow the advice given and re-run, libtoolize
should complain about the mismatch :(

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

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