Hi Eric, just a quick reply before bedtime ...
On 11/02/2012 10:39 PM, Eric Blake wrote:
> On 11/02/2012 06:27 AM, Stefano Lattarini wrote:
>> This change fixes the existing issues with AC_CONFIG_MACRO_DIRS
>> containing newlines:
>> <http://lists.gnu.org/archive/html/autoconf-patches/2012-11/msg00000.html>
>>
>> Likely, it will also allow a less involved implementation of the
>> AM_EXTRA_RECURSIVE_TARGETS macro (but that is left for potential
>> follow-up patches).
>>
>> * aclocal.in (trace_used_macros): When calling autom4te, pass its
>> '--trace' option an argument containing '${::}%' rather than '$1'.
>> According to the autoconf manual (as of version 2.69), that will expand
>> to the concatenation, with the '::' string, of all the arguments passed
>> to a macro, with all newline characters in such arguments smashed.
>> Related adjustments when handling the macro AC_CONFIG_MACRO_DIRS, to
>> ensure leading whitespace in its argument are handled correctly.
>> * t/aclocal-macrodirs.tap ("AC_CONFIG_MACRO_DIRS: extra whitespace"):
>> No longer declare it as an xfailing test.
>
> You may not need this, if we go with my autoconf approach of tracing
> _AC_CONFIG_MACRO_DIR which already split things so that there are no
> newlines in the first place.
>
If _AC_CONFIG_MACRO_DIR is meant to be traced by external tools (like
Automake and Libtool are, despite a tighter-than-usual integration with
autoconf), we should find a better name, one that doesn't suggest it to
be an internal macro. Especially because we document that the tracing
of it is *the way* for third-part tools to interact with it. Maybe
something like 'AC_CONFIG_MACRO_DIRS_TRACE_ME' is clear & proper enough?
That said, I believe the current flying patch series should go into the
Automake and Autoconf repositories as they are; my further fixlets (the
introduction of the 'm4require-without-m4defun' "singleton" warning
category) and your proposed enhancements (the new '_AC_CONFIG_MACRO_DIR'
macro, or an equivalent one with a "public" name) might go on the top of
them. Not only would that reduce confusion among us developers ("what
is the correct patch series to apply where now?"), but would also give
a more faithful view of the development history in the git repositories.
WDYT?
Thanks,
Stefano
