Re: [PATCH 1/2] AC_CONFIG_MACRO_DIRS: new macro, mostly for aclocal

[Eric Blake]

On 10/16/2012 03:38 PM, Andrew W. Nosenko wrote:
> Excuse, may be it's too late to party, but...  What is the reason to
> to invent yet another macro name?  Anyway in the most packages there
> will be one and the only one line:
>     AC_CONFIG_MACRO_DIR([m4])
> And even when the many dirs are need, they will be written one by one
> in the theirs own macro call:
>     AC_CONFIG_MACRO_DIR([m4])
>     AC_CONFIG_MACRO_DIR([sub/m4])
>     AC_CONFIG_MACRO_DIR([pack/m4])
> (The reasons for such stacking is the same as the reasons for lineup
> an arguments in a function call with a number of parameters in the
> C-like languages -- aesthetics and ability to easy comment out some of
> them.  The later becomes even more important in languages with the
> only one style of comment -- from comment-char to the end-of-line,
> like autoconf language.)

The problem is that existing tools (here's looking at you libtool) are
inconsistent if you HAPPEN to use AC_CONFIG_MACRO_DIR - some use the
first directory, others use the last, and some crash altogether.
Back-compat requires that we have a new macro, so that new tools that
agree on a common sane semantics use the new name, and where the new
name calls AC_CONFIG_MACRO_DIR() exactly once, on the first directory,
if AC_CONFIG_MACRO_DIR had not already been used, for best
interoperability with old tools.

I haven't looked closely at these patches, so I still may end up
tweaking the design a bit, but I appreciate Stefano stepping up to fill
in a gap from my apparent lack of time at writing a patch that we first
discussed that I should attempt more than a month ago.

> 
> Therefore, a question raises: why to invent the new macro name?
> Please note, I don't say about implementation.  I say about name.  If
> someone whant to write (or generate, which is more probable) a number
> of dirs in the one macro call -- no problems:
>     AC_CONFIG_MACRO_DIR([m4], [sub/m4], [pack/m4])
> or how it intended to be written, but in wast majority of cases I
> expect the name in singular form to be more appropriate.  Just change
> it's implementation, but left the name as is.  Allowing multiple dirs
> where only one was allowed is backward compatible.
> As a bonus: No needs in playing the game with "this macro is obsolete,
> but we don't say you that evenn with -Wobsolete for backward
> compatibility".

I think we _can't_ mark the old macro obsolete, but at the same time, we
must document that the old macro may appear _at most once_, and _prior
to any use of the new macro_.

> If te plural form (AC_CONFIG_MACRO_DIRS) is needed for some very heavy
> reason, then it may me made just an alias to the AC_CONFIG_MACRO_DIR.

Using just the m4 perspective, yes, the macros are aliases (they both do
nothing).  But from the autoconf --trace perspective, having two macros
matters, because not all tools used --trace (older libtool was using
sed, rather poorly), and we don't want to break interoperability with
old tools, all while still allowing new tools (automake 1.13) to take
advantage of the multiple directories.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature