[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tracing from aclocal
Re: tracing from aclocal
Mon, 18 Aug 2003 16:47:56 +0200
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
> 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
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
> 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
>>> * 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
verbose "$configure_ac: not using aclocal";
# 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
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
> 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...
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, 2003/08/14
- 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