autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] AC_CONFIG_MACRO_DIR: accept more than one argument


From: Stefano Lattarini
Subject: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIR: accept more than one argument
Date: Thu, 20 Sep 2012 20:32:06 +0200

Hi Nick.

On 09/20/2012 05:42 PM, Nick Bowler wrote:
>
> Just to chime in on the real-world usefulness of these macros: as far as
> I can tell, AC_CONFIG_MACRO_DIR does exactly one thing today.
>
Well, according to the Autoconf documentation, not even that ;-)

    AC_CONFIG_MACRO_DIR (dir)

    Specify dir as the location of additional local Autoconf macros.  This
    macro is intended for use by future versions of commands like autoreconf
    that trace macro calls.  It should be called directly from 'configure.ac'
    so that tools that install macros for aclocal can find the macros'
    declarations.

See below for a more serious discussion ...

> It allows
> you to select between the following 3 possible behaviours of libtoolize:
> 
>   (a) libtoolize works properly, and prints no warning.
>   (b) libtoolize works properly, and prints a warning that
>       AC_CONFIG_MACRO_DIR is missing.
>   (c) libtoolize fails gratuitously, and prints an error that
>       AC_CONFIG_MACRO_DIR is wrong.
> 
> I am not aware of any other tool which uses the value passed to
> AC_CONFIG_MACRO_DIR in any meaningful way.
>
Thanks for this precise summary about the current (sad) state of the
AC_CONFIG_MACRO_DIR macro.

The point of the Autoconf change I'm pushing for, and the follow-up ones
in Automake I'm planning about, is exactly be to start honouring the
AC_CONFIG_MACRO_DIR{,S} macro in aclocal and autoreconf, getting rid of
the ACLOCAL_AMFLAGS hack (eventually).  A little late (~10 years, as you
note below), but better late then never ...

> Moreover, libtoolize does
> not seem to use the value for anything other than these pointless checks:
> it apparently always looks at ACLOCAL_AMFLAGS to decide where to copy
> macros.
> 
> (Corollary: for compatibility with any existing version of libtool all
> you need to do is delete all invocations of AC_CONFIG_MACRO_DIR from
> configure.ac)
> 
> Therefore, AC_CONFIG_MACRO_DIR is ill-specified to begin with (not
> clear what multiple invocations are supposed to do), untestable
> (as nothing actually uses it), useless (for the same reason), and
> counterproductive (as it requires duplicating information for no
> benefit).  Looking at the history, this has been the case for almost
> 10 years now.
> 
> For these reasons, I removed it from all of my packages a while ago
> (so I get a gratuitous warning from libtoolize: oh well).  Unless the
> new macro fixes all of these problems, I'm afraid it will suffer a
> similar fate.  But maybe, just maybe, AC_CONFIG_MACRO_DIRS will gain
> traction where AC_CONFIG_MACRO_DIR never did...
>
I think it will, because:

   - aclocal and autoreconf will actually honour AC_CONFIG_MACRO_DIRS,
     instead of ignoring it as they sadly did with AC_CONFIG_MACRO_DIR.
     So there will be a point in using it.

   - Once AC_CONFIG_MACRO_DIRS is implemented, I will start deprecating
     ACLOCAL_AMFLAGS, and remove it in the next major automake version
     (maybe 1.14, more probably 1.15).

Regards,
   Stefano



reply via email to

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