automake-patches
[Top][All Lists]
Advanced

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

Re: let's trace?


From: Tom Tromey
Subject: Re: let's trace?
Date: 13 Apr 2002 13:13:30 -0600

>>>>> "adl" == Alexandre Duret-Lutz <address@hidden> writes:

adl> [I've just learnt that nuking code can be very delighting.]

Yeah.  This patch looks especially delightful.

adl> The test suite ran without error (not a surprise nor a proof of
adl> anything).

Yeah :-(.  It's getting better, in that some of the newer tests run
configure and make and so serve as "smoke tests".  Improving the test
suite to test more stuff is always worthwhile.

adl> I know of at least one diagnostic that the trace code doesn't
adl> make: it doesn't warn that AC_CONFIG_HEADER must be rewriten as
adl> AM_CONFIG_HEADER.  I think we could build two hashes using the
adl> arguments for each macros as keys, and finally make sure both
adl> sets of keys are equals at the end of the scan.  Or can you think
adl> of something simplier to do? (like tricks at the m4 level, I don't
adl> know.)

We need AM_CONFIG_HEADER to let us make the stamp files.
I think we can do this using m4 tricks, just like we do with other
things (dependencies) from init.m4.  That seems most robust to me,
it means the user has one less AM_/AC_ split to remember, and it means
one less error mode in automake.

adl>    * lib/am/header-vars.am

This .am file is special.  See define_standard_variables.  Maybe we
need more tests to test for this stuff.  As I recall this special code
lets us use `+=' on built-in variables.  Anyway, removing definitions
from this file might not be fully correct.

I'm all for moving to traces as soon as possible.  It is clearly the
way forward and we want the maximum amount of time to find the
inevitable bugs.

Tom



reply via email to

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