Re: tracing from aclocal

[Akim Demaille]

>>> "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
m4/init.m4:AM_INIT_AUTOMAKE
m4/init.m4:_AC_AM_CONFIG_HEADER_HOOK
m4/amversion.m4:AM_AUTOMAKE_VERSION
m4/amversion.m4:AM_SET_CURRENT_AUTOMAKE_VERSION
m4/options.m4:_AM_MANGLE_OPTION
m4/options.m4:_AM_SET_OPTION
m4/options.m4:_AM_SET_OPTIONS
m4/options.m4:_AM_IF_OPTION
m4/sanity.m4:AM_SANITY_CHECK
m4/missing.m4:AM_MISSING_PROG
m4/missing.m4:AM_MISSING_HAS_RUN
m4/auxdir.m4:AM_AUX_DIR_EXPAND
m4/install-sh.m4:AM_PROG_INSTALL_SH
m4/strip.m4:AM_PROG_INSTALL_STRIP
m4/lead-dot.m4:AM_SET_LEADING_DOT
m4/depend.m4:_AM_DEPENDENCIES
m4/depend.m4:AM_SET_DEPDIR
m4/depend.m4:AM_DEP_TRACK
m4/depout.m4:_AM_OUTPUT_DEPENDENCY_COMMANDS
m4/depout.m4:AM_OUTPUT_DEPENDENCY_COMMANDS

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

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

begin-language: "Autoconf"
args: --prepend-include /usr/local/share/autoconf
args: --cache=autom4te.cache
args: autoconf/autoconf.m4f
args: acsite.m4?
args: aclocal.m4?
args: --mode 777
args: --language Autoheader-preselections
args: --language Automake-preselections
args: --language Autoreconf-preselections
args: --language Autoscan-preselections
args: --language M4sh
end-language: "Autoconf"

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

s/were/was/

 > +    conditionally.