Re: [PATCH] Add autom4te traces for likely future Automake macros.

[Eric Blake]

On 09/19/2010 02:29 AM, Ralf Wildenhues wrote:
> * lib/autom4te.in (Automake-preselections): Trace
> AM_MAKEFILE_INCLUDE, AM_NLS, AM_POT_TOOLS, AM_PATH_GUILE,
> AM_PROG_MOC, AM_XGETTEXT_OPTION, _AM_MAKEFILE_INCLUDE.
>
> Signed-off-by: Ralf Wildenhues<address@hidden>
> ---
>
> * Ralf Wildenhues wrote on Sat, Sep 18, 2010 at 07:23:54AM CEST:
> > I've considered adding a few names to lib/autom4te.in speculatively,
> > since Automake will be needing more of those.  I'm not sure if that
> > is sensible before we have code, but it sure could help not having
> > to require unreleased Autoconf; as of now, I'm not aware of these
> > new macro branches needing other support in Autoconf explicitly.
>
> A patch to this end would be this (with type AM_PROG_MOC fixed).

I went ahead and applied this as-is.  All that hurts in tracing an extra 
macro is a little bit of memory during m4 execution, and some disk space 
in autom4te.cache if the macro is encountered.  But it sure helps for 
when you do define ways to exploit the trace, avoiding extra m4 runs 
merely because the trace wasn't automatically available on the first run.

Meanwhile, I've been wondering if there is any better way that we can 
make pre-trace selections depend on a database file maintained by 
automake, rather than having to tweak autoconf every time we think of a 
new one.  I'm thinking of adding a new macro, m4_pretrace(NAME), which 
enables the effects of pre-tracing on a given macro NAME at m4 runtime 
rather than at autom4te configuration file time.

The main effect of pretracing in the current use of the autom4te 
configuration file is to turn on m4's --trace=name command line options, 
so that all instances of calls to the macro name will be traced.  But 
the m4_traceon builtin can do that dynamically; and if the trace is 
turned on soon enough, the resulting trace file will show no difference 
from command-line vs. dynamic tracing.  And we already document that 
some macros, like AM_INIT, must be called first anyways; not to mention 
that things like AC_BEFORE can enforce ordering if you are worried about 
a pre-traced macro being mistakenly called before AM_INIT has had a 
chance to trace it.

Meanwhile, the other effect of pretrace is that autom4te maintains a 
file autom4te.cache/requests, to see which traces it has available to 
avoid rerunning m4 just to collect another trace.  But if autom4te 
always pre-traces m4_pretrace, then it can update the requests file 
after a run to state what additional macros ended up in the trace, even 
though they were not known at the time the m4 run started.

So, with m4_pretrace in hand, all automake would have to do is add a 
call to m4_pretrace([AM_NLS]) inside AM_INIT, rather than asking 
autoconf to change the autom4te config file yet again.  But, that's 
certainly a post-2.68 patch, which means that automake can't use that 
mechanism to add traces until autoconf 2.69.  Oh well, food for thought 
for things to do post-release.

> +2010-09-19  Ralf Wildenhues<address@hidden>
> +
> +       Add autom4te traces for likely future Automake macros.
> +       * lib/autom4te.in (Automake-preselections): Trace
> +       AM_MAKEFILE_INCLUDE, AM_NLS, AM_POT_TOOLS, AM_PATH_GUILE,
> +       AM_PROG_MOC, AM_XGETTEXT_OPTION, _AM_MAKEFILE_INCLUDE.
> +
>   2010-09-16  Ralf Wildenhues<address@hidden>

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org