Re: strange include/trace behavior

[Akim Demaille]

 > I find the following output confusing
 > % cat configure.ac
 > AC_INIT(a,b)
 > include(x1.m4)
 > sinclude(x2.m4)
 > m4_include(x3.m4)
 > m4_sinclude(x4.m4)
 > AC_OUTPUT
 > % touch x{1..4}.m4
 > % autoconf --trace=m4_sinclude
 > configure.ac:3:sinclude:x2.m4
 > configure.ac:5:m4_sinclude:x4.m4
 > % autoconf --trace=m4_include
 > configure.ac:4:m4_include:x3.m4
 > % autoconf --trace=sinclude
 > configure.ac:3:sinclude:x2.m4
 > configure.ac:5:m4_sinclude:x4.m4
 > % autoconf --trace=include
 > configure.ac:4:m4_include:x3.m4
 > % fgrep 'include(' configure
 > include(x.m4)


 > Why do tracing for m4_sinclude or sinclude always returns _both_
 > variants?

Because GNU M4 is guilty of not being clear about traces, so we had to
workaround this.  And the safest is to ask for all of them.

The issue is quite delicate actually, if you just think about all the
renaming that's going on, including on builtins.  If you pass m4 a
trace request on the command line, should it trace the name, or the
macro (errr, bulletin at that time) body that has this name at that
moment, and make it sticky to future names?

 > Why is sinclude() expanded and include() not? 

Dunno, I should have a look.

 > Why does tracing for include returns m4_include?

Because include is renamed as m4_include.

 > Automake needs to trace for these.  Currently it only traces
 > m4_include and m4_sinclude and abort when Autoconf returns an
 > unrequested trace (such as sinclude).  Obviously I need to
 > adjust that code in some way, but given the above output I'm not
 > sure what I'm expected to do.  Should I trace for two, three, or
 > four macros?

autom4te makes an attempt to hide the user from the m4 problems (CVS
and 1.4 were not agreeing on this regard).  Be my guest, and RTFC ;)

(from autom4te.in)

# %M4_BUILTIN_ALTERNATE_NAME
# --------------------------
# The builtins are renamed, e.g., `define' is renamed `m4_define'.
# So map `define' to `m4_define' and conversely.
# Some macros don't follow this scheme: be sure to properly map to their
# alternate name too.
#
# This is because GNU M4 1.4's tracing of builtins is buggy.  When run on
# this input:
#
# | divert(-1)
# | changequote([, ])
# | define([m4_eval], defn([eval]))
# | eval(1)
# | m4_eval(2)
# | undefine([eval])
# | m4_eval(3)
#
# it behaves this way:
#
# | % m4 input.m4 -da -t eval
# | m4trace: -1- eval(1)
# | m4trace: -1- m4_eval(2)
# | m4trace: -1- m4_eval(3)
# | %
#
# Conversely:
#
# | % m4 input.m4 -da -t m4_eval
# | %
#
# So we will merge them, i.e.  tracing `BUILTIN' or tracing
# `m4_BUILTIN' will be the same: tracing both, but honoring the
# *last* trace specification.
#
# FIXME: This is not enough: in the output `$0' will be `BUILTIN'
# sometimes and `m4_BUILTIN' at others.  We should return a unique name,
# the one specified by the user.
#
# FIXME: To be absolutely rigorous, I would say that given that we
# _redefine_ divert (instead of _copying_ it), divert and the like
# should not be part of this list.
my %m4_builtin_alternate_name;
@m4_builtin_alternate_name{"$_", "m4_$_"} = ("m4_$_", "$_")
  foreach (grep { !/m4wrap|m4exit|dnl|ifelse|__.*__/ } @m4_builtin);
@m4_builtin_alternate_name{"ifelse", "m4_if"}   = ("m4_if", "ifelse");
@m4_builtin_alternate_name{"m4exit", "m4_exit"} = ("m4_exit", "m4exit");
@m4_builtin_alternate_name{"m4wrap", "m4_wrap"} = ("m4_wrap", "m4wrap");