[Bug-gnulib] Re: tracing from aclocal

[Akim Demaille]

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

Yes.  That's when I started the war against underquoted AC_DEFUN's :)

 > 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

Gee.  I thought this was over :(


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

Any means that could guide people in writing proper M4 should be
used.


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

You could ship an aclocal that would be a wrapper of Autoconf's.



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

Would that guarantee that we keep the aclocal.m4 time stamp
Make-inert?  Otherwise, it sounds good.  Still, introducing an
intermediate "language", without "aclocal.m4?" would do the same, but
cleaner.



 >>> * 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).

Indeed.  That's something Paul Eggert tracked down, and solved in
autoreconf:

  if (!$uses_aclocal)
    {
      verbose "$configure_ac: not using aclocal";
    }
  else
    {
      # Some filesystems have sub-second time stamps, and if so we may
      # run into trouble later, after we rerun autoconf and set the
      # time stamps of input files to be no greater than aclocal.m4,
      # because the time-stamp-setting operation (utime) has a
      # resolution of only 1 second.  Work around the problem by
      # ensuring that there is at least a one-second window before the
      # time stamp of aclocal.m4t in which no file time stamps can
      # fall.
      sleep 1;

      run_aclocal ($aclocal, $aclocal_flags);
    }

Is this really all that can do a modern system?  A one second accuracy
on time stamps?

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

M4 is currently a serious bottleneck in our tool chain.  I'm not found
of making this worse.  I might not understand fully what you are
referring to (maybe it's time to have a diner together :), but it
seems to me that that would introduce superfluous runs in some cases.

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

That should work.


 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 :(

Na, this ought to be done by me.  Time to steal the Channels I guess...