[Bug-gnulib] Re: tracing from aclocal

[Alexandre Duret-Lutz]

>>> "Akim" == Akim Demaille <address@hidden> writes:

[...]

 Akim> I used to import _all_ the macros at this stage.  IIRC, I
 Akim> was building an aclocal.m4 with an m4_include for each
 Akim> file, and then, using this aclocal.m4, do something like:

That's neat!  I foresee this will cause many troubles with
macros installed at several places (e.g., on the system and in
the package; or at two place on the system) which are using an
underquoted AC_DEFUN.

Underquoted AC_DEFUN is still fairly common, I'm afraid. On my
system I get

% grep AC_DEFUN /usr/share/aclocal/* | fgrep -v '([' | wc -l
47

I used to run a modified version of aclocal that would warn when
reading such underquoted definitions.  I never installed this
patch because it caused lots of warnings (aclocal always reads
all macros installed on the system), and these warnings were
not the fault of the package being configured.

Maybe I was too shy and it's time enforce proper quoting, be it
through user complaints?  If so, I'd suggest we add the warning
in 1.8, and delay your gathering trick to 1.9.

After this, I think the only thing that prevents moving the
aclocal functionality to Autoconf is the handling of multiple
Automake versions.

[...]

 >> 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?

 Akim> Yes, you can, although it's definitely clumsy...
[...]

 Akim> passing these arguments to autom4te.  That's a lot of internal
 Akim> knowledge to replace :(  If you can't mv aclocal.m4 while preserving
 Akim> the time stamp, 

Wait a minute, I didn't thought about that.  I think the following
should work (modulo caching issues):

 1. mv aclocal.m4 aclocal.t1
 2. build aclocal.t2 from potential macros
 3. autom4te --language=autoconf --trace=... configure.ac aclocal.t2
 4. build the final output in memory
 5. if it's identical to aclocal.t1, then mv aclocal.t1 aclocal.m4
    otherwise output the new aclocal.m4

[...]

 >> * If aclocal calls autoconf --trace, then the following
 >> call to autoconf does not print any diagnostics.  So

I think I underestimated this problem.  That fact that cached
runs do not output diagnostics is certainly an issue, but we
have another one: why is the second autoconf run (i.e., the main
one) cached?

Indeed, when --trace is first used from aclocal, it's against
the unstripped aclocal.m4.  When autoconf is latter called
to build configure, it reads the stripped version of aclocal.m4.

The tests/obsolete.test failure I mentioned is easily explained
because both the unstripped and stripped versions are equal.
But I've made a test using AM_GNU_GETTEXT([external]), where
both versions are different, and caching still occurs.  As I
understand it, this is because the second version of aclocal.m4
overrides the first within the same second, so autom4te sees the
same timestamp.  If aclocal sleeps for 1sec between both writes,
then caching does not occur (as expected).


In the case where we switch to your trick to compute the
intermediate aclocal.m4, then there is no chance that this
intermediate aclocal.m4 be equals to the final aclocal.m4.  The
cache ought to be always invalided after aclocal has run.

Hence I think it would make sense to simply fix step 3. above to

 3. autom4te --no-cache --language=autoconf --trace=... configure.ac aclocal.t2
             ^^^^^^^^^^

Sounds like (I still haven't tested) that would cure all issues,
and at least that doesn't require any change to Autoconf.

[...]

 Akim> Option 1.  Change the m4 code for warnings to be always output with a
 Akim> protocol for autom4te to be able to filter them.  Cache this output,
 Akim> and at each execution of autom4te, issue the warnings.  This implies
 Akim> that all the executions of autom4te will trigger the warnings.

This sounds better to me.  But I can't offer you to do it :(

[...]

 Akim> s/were/was/

Thank you.
-- 
Alexandre Duret-Lutz