[Top][All Lists]

[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: Nick Bowler
Subject: Re: [PATCH 1/2] AC_CONFIG_MACRO_DIR: accept more than one argument
Date: Thu, 20 Sep 2012 11:42:36 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On 2012-09-20 16:53 +0200, Stefano Lattarini wrote:
> Reference:
> <>
> On 08/21/2012 11:37 AM, Stefano Lattarini wrote:
> > 
> > On 07/04/2012 01:51 PM, Stefano Lattarini wrote:
> >> On 07/04/2012 01:28 PM, Eric Blake wrote:
> >>> I think we're stuck for compatibility with providing a new macro for
> >>> listing subsidiary directories, and that users that plan to interact
> >>> with old libtool must use something like:
> >>>
> >>> AC_CONFIG_MACRO_DIR([dir1])
> >>> AC_CONFIG_MACRO_DIRS([dir2 dir3])
> >>> AC_CONFIG_MACRO_DIRS([dir4])
> >>>
> >>> where the new macro can stack or take whitespace lists.  The new macro
> >>> can also auto-call AC_CONFIG_MACRO_DIR() for its first argument for new
> >>> libtool that traces rather than using sed, but if you are porting to
> >>> older libtool, explicitly spelling out the old name is important.
> >>>
> >> OK.  The new code to support this in aclocal will amount to one line of
> >> code :-)  And the 'AC_CONFIG_MACRO_DIRS' name is preferable IMHO, being
> >> more faithful to the intended semantics (several directories supported).
> >>
> >> Anyway, to avoid a continuous accretion of backward-compatibility cruft, I
> >> think we should also "deprecate" AC_CONFIG_MACRO_DIR in the documentation,
> >> stating that it should only be required by older libtools, and add a FIXME
> >> comment to its definition in general.m4 telling that it should be removed
> >> by 2014 or so.
> >>
> > Ping on this?
> >
> Another ping.  Automake 1.13 will need to know the interface of this
> new Autoconf feature in order to integrate with it correctly, and start
> deprecating ACLOCAL_AMFLAGS (in documentation only until Autoconf 2.70
> is out; after that, also with warnings in the 'obsolete' category).

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

(Corollary: for compatibility with any existing version of libtool all
you need to do is delete all invocations of AC_CONFIG_MACRO_DIR from

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

Nick Bowler, Elliptic Technologies (

reply via email to

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