[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tracing from aclocal
Re: tracing from aclocal
Thu, 14 Aug 2003 07:36:33 +0200
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
>>> "Bruno" == Bruno Haible <address@hidden> writes:
Bruno> Can someone please fix 'aclocal' so that, after
Bruno> determining which macros are potentially needed, it runs
Bruno> autoconf with tracing enabled, to determine which macros
Bruno> are really needed?
That's indeed the right thing to do. Well, I think: that's what used
to do my suggestions for replacing aclocal within Autoconf :)
> Anyway, the following patch (against CVS HEAD) updates aclocal
> to build aclocal.m4 in two steps as you suggested.
> 1a) scan for potential macros
> 1b) build aclocal.m4 with all potential macros
I used to import _all_ the macros at this stage. IIRC, I was building
an aclocal.m4 with an m4_include for each file, and then, using this
aclocal.m4, do something like:
~/src/am % autom4te -l autoconf --trace=AC_DEFUN:'$f:$1' m4/*.m4 | sed 20q
to gather the macros and their locations.
> 2a) trace for actual macros
> 2b) build aclocal.m4 with all actual macros
> I have two problem with this change. I think both of them
> should be addressed in Autoconf, but maybe I'll have other
> * This breaks tests/aclocal7.test. This test make sure
> we do not overwrite aclocal.m4 needlessly (i.e., when
> the content is the same and no dependency is newer).
> Obviously this is impossible to do if aclocal.m4 has
> to be written twice.
> I could try to reset the timestamp of aclocal.m4 afterwards
> in case the file really shouldn't have changed, but that
> sound clumsy. Especially there will still exist a period
> where aclocal.m4 is fresh, and that is likely to trouble
> parallel makes.
> What I'd like is that step 1b) builds a temporary file,
> say aclocal.tmp, and step 2a) tells autoconf to use
> this temporary file instead of aclocal.m4.
> Maybe autom4te already allows this? Akim?
Yes, you can, although it's definitely clumsy... Running autoconf is
basically the same as running autom4te -l autoconf, i.e.:
args: --prepend-include /usr/local/share/autoconf
args: --mode 777
args: --language Autoheader-preselections
args: --language Automake-preselections
args: --language Autoreconf-preselections
args: --language Autoscan-preselections
args: --language M4sh
passing these arguments to autom4te. That's a lot of internal
knowledge to replace :( If you can't mv aclocal.m4 while preserving
the time stamp, then the most reliable alternative would be to
introduce in autom4te.cfg an intermediate "language" that would
include all the args except aclocal.m4.
> * If aclocal calls autoconf --trace, then the following
> call to autoconf does not print any diagnostics. So
> aclocal && autoconf -Wall
> has exactly the same effect as
> aclocal && autoconf
> only the standard diagnostic are issued, and this is
> done while aclocal run. This is the reason for
> the change in tests/obsolete.test in the patch below.
> Not that this second issue is quite independent from
> this patch. I think people running
> `automake && autoconf -Wall' instead of `autoconf -Wall && automake'
> get into the same trouble (although both uses are equally valid
> from the Makefile dependencies point of view).
Yes, this is a known issue, that is becoming really troublesome. I
had postponed it's resolution since it was still the (probabilistic)
rule that autoconf be run first.
Option 1. Change the m4 code for warnings to be always output with a
protocol for autom4te to be able to filter them. Cache this output,
and at each execution of autom4te, issue the warnings. This implies
that all the executions of autom4te will trigger the warnings.
Option 2. Consider that -W is a cache-invalidating option (i.e., if
it has changed since the last run, the cache must not be used).
These issues can make it into the next Autoconf if you want.
> BTW you owe me a fuse.
Who's "you"? :)
> + - aclocal now uses Autoconf's --trace to detect macros which are actually
> + used and will no longer include unused macros simply because they
> + where mentioned. This were often the case for macros called
> + conditionally.
Re: tracing from aclocal, Alexandre Duret-Lutz, 2003/08/18
- tracing from aclocal (Was: Re: [Bug-gnulib] proposed gettext.m4 patch for inttypes.h (merge from coreutils)), Alexandre Duret-Lutz, 2003/08/12
- Re: tracing from aclocal,
Akim Demaille <=
- Re: tracing from aclocal, Alexandre Duret-Lutz, 2003/08/15
- Re: tracing from aclocal, Alexandre Duret-Lutz, 2003/08/18
- Re: tracing from aclocal, Akim Demaille, 2003/08/19
- Re: tracing from aclocal, Alexandre Duret-Lutz, 2003/08/21
- Re: tracing from aclocal, Alexandre Duret-Lutz, 2003/08/23