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
+...@command{aclocal} (in contrast to e.g.@: @command{automake}) doesn't
+work by consistently using m4 tracing, but must sometimes resort to
+...@emph{grepping 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 (g...@gnu.org)
