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

[Stefano Lattarini]

On Friday 05 November 2010, Gary V wrote:
> 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.
Integrating this in the next version of aclocal would be nice indeed.
Anyway, I still think that documenting the current limitations of aclocal
in the "maint" branch is worthwile, especially in the case we'll have to
do another 1.11.x release, or in case aclocal won't be fixed before the
next automake release (which, alas, is not that unlikely).
> 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.
Good.  Also, it would be nice if you could ping the automake list about
this when youre done, to let us see what can be learned from your
implementation.
 
> 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''.
Yes, I've found the mail.  Thanks for pointing it out.
> 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.
In the long run, that would be the best solution (as said also in the
Automake's manual ;-).

Thanks,
   Stefano