[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: [PATCH] Add autom4te traces for likely future Automake macros.
Date: Wed, 22 Sep 2010 16:22:56 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100907 Fedora/3.1.3-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.3

On 09/19/2010 02:29 AM, Ralf Wildenhues wrote:
* lib/ (Automake-preselections): Trace

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/ 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/ (Automake-preselections): Trace
  2010-09-16  Ralf Wildenhues<address@hidden>

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library

reply via email to

[Prev in Thread] Current Thread [Next in Thread]