[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool 2.4: questionable advice
From: |
Ralf Wildenhues |
Subject: |
Re: libtool 2.4: questionable advice |
Date: |
Tue, 5 Oct 2010 06:36:45 +0200 |
User-agent: |
Mutt/1.5.20 (2010-08-04) |
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