Re: [PATCH] {maint} Document in detail some limitations of aclocal.

[Gary V. Vaughan]

Hi Stefano,

Stefano Lattarini wrote:
> +Due to both intrinsic and historical reasons, @command{aclocal} is
> +far from perfect.  The most noteworthy limitation, which macro authors
> +and @command{aclocal} users should always be aware of, is that
> address@hidden (in contrast to e.g.@: @command{automake}) doesn't
> +work by consistently using m4 tracing, but must sometimes resort to
> address@hidden the contents of the scanned files} when looking for macro
> +definitions and file inclusions.  This means that perfectly valid m4
> +constructs and usages might cause unexpected behaviours or even spurious
> +failures.

While that is certainly true with the current implementation, don't 
forget that I already invented a new way for tools that must run before
autoconf to use m4 for tracing instead of resorting to grep like this in 
my bootstrap rewriting threads on bug-gnulib.  The effort involved in 
applying that method to the existing aclocal is probably little more 
than it was to write this patch... When I have more time, I intend to 
port the method to libtool and finish submitting the new gnulib bootstrap.

http://lists.gnu.org/archive/bug-gnulib is not responding at the moment,
but I posted a recent version of my bootstrap rewrite including the 
grepless tracing on 2010-10-09 in the thread ``Re: [PATCH] bootstrap: 
add hook for altering gnulib.mk, for Bison''.  The key to generalising 
it is, I think, adding another `language' to autoconf purely for tracing 
when failed `m4_include's must be ignored.

When I have *a lot* more time, I plan to finally get around to releasing 
m4-2.0, or at least backporting the macro search path enhancements into 
m4-1.4.x so that we can start the process of removing aclocal entirely 
and teaching autoconf to find it's own macros unaided.

Cheers,
--
Gary V. Vaughan (address@hidden)