Re: libtool 2.4: questionable advice

[Ralf Wildenhues]

Hello Gary, Bruno,

* Gary V. Vaughan wrote on Tue, Oct 05, 2010 at 03:01:40AM CEST:
> 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.

It's not that aclocal added a new way of declaring a macro file, it's
that *parsing* configure.ac reliably is *not* possible unless you
already know the macros you are going to include, and from which files.

Example:

AC_INIT
THIRD_PARTY_MACRO([foo],
                  [AC_CONFIG_MACRO_DIR([in-foo])],
                  [AC_CONFIG_MACRO_DIR([not-in-foo])])

Grepping configure.ac is the real kludge, ACLOCAL_AMFLAGS is the
"redundant" way to also allow more complicated setups.  Let's not
prevent the complex setup just to make the simple setup a wee bit
simpler.

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

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

> Actually, if you follow the advice given and re-run, libtoolize
> should complain about the mismatch :(

Cheers,
Ralf