Hi Chuck,
On 6 Nov 2011, at 00:23, Charles Wilson wrote:
> On 11/5/2011 12:40 PM, Gary V. Vaughan wrote:
>> By the end of this particular set, libtoolize will have moved from the kludgy
>> sed based interrogation of configure.ac to probe the arguments to various
>> important macros so that it can determine what files to copy and where... to
>> the much more splendid and reliable M4 based tracing mechanism I originally
>> wrote for bootstrap last year before adoption into gnulib stalled.
>
> IIUC, in the past libtoolize *itself* has not had any dependency on m4.
> Granted, it wasn't much use without autoconf, which needed m4, so most users
> of libtoolize would have had m4 installed anyway. But this change will add a
> *direct* dependency on m4, right?
>
> That's ok with me, as it makes no *real* difference, but it should be
> documented somewhere.
Good point. And, actually, we do support the use of `libtoolize --subproject
--ltdl'
into a non-Autotools parent project, so it would be nice if we didn't require
GNU M4
in that case. Luckily, moving to the $require_resource architecture in that
area means
that we run the M4 scans lazily, so when there is no configure.ac to scan,
execution
of the new extract-trace script (the real GNU M4 dependency) never happens.
Nonetheless, it would be nice if I didn't break that in a future update, so I've
added a new test to PATCH 3/7 from this series to do that... as well as a NEWS
item:
- GNU M4 is required to run libtoolize in a directory with a
`configure.ac' (or `configure.in') that needs tracing to determine
what modes and directories have been specified.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
