First, a little bit of context for people who don't read
autoconf-patches.
<context>
One of the major failures of Autoconf is its total lack of openness to
other tools, and in particular it is wrong that automake parses
configure.in and so on. Nobody better than m4 will read m4, nobody
better than Autoconf can tell what autoconf does.
Based on this idea, a patch was committed which uses m4's tracing
features to provide the `client' with an easy to read trace of the
macro expansions. This is much safer than parsing configure.in. For
instance, consider the fact that automake needs to know all the output
variables. It both reads configure.in and aclocal.m4 to find
AC_SUBST, and also hard codes a list of `AC_MACRO -> output
variables'. Hick.
~/src/ace % ./autoconf --trace AC_SUBST nostromo 9:51
configure.in:2:AC_SUBST:SHELL
configure.in:2:AC_SUBST:CFLAGS
configure.in:2:AC_SUBST:CPPFLAGS
configure.in:2:AC_SUBST:CXXFLAGS
configure.in:2:AC_SUBST:FFLAGS
[CUT]
This is much better, automake just has to parse this.
But, the patch that was committed smashes all the new-lines in the
arguments:
AC_OUTPUT(Makefile
src/Makefile)
gives:
configure.in:373:AC_OUTPUT:Makefile src/Makefile
in addition, for technical but unjustified reasons, it will choke on
any `@'.
Alexandre added the wish to specify which argument you want (for
instance automake is only interested in $1 of AC_OUTPUT etc.). He
also spotted the fact that no difference is made between FOO([a,b])
and FOO(a, b). He doesn't want the `@' brain-damage (but why??? ;),
and suggested an implementation based on hooks on the macros (other
macros executed when a main macro is expanded).
</context>
I have implemented the hook stuff. It's a pain, but it's doable.
There are two failures:
- the code for `ifset' is no longer valid. When you check the `defn'
of a macro, it cannot be empty since there is the code to launch
the hook.
You can fix this by using a different macro to define pseudo-variables
(the case above) and for the macros which `perform' something. Of
course one will insert the code to run the hooks, while not the other.
- every macro becomes extremely picky on the quotes, since there is
embedded code which really depends upon [ and ].
Well, Autoconf itself had no problem, but a certain package for
portably building libraries has several times this code:
changequote(<<, >>)dnl
<< --enable-shared[=PKGS] build shared libraries
[default=>>AC_ENABLE_SHARED_DEFAULT],
changequote([, ])dnl
note that AC_ENABLE_SHARED_DEFAULT is evaluated with << and >> as
quotes, so it chokes. Once you wrote
changequote(<<, >>)dnl
<< --enable-shared[=PKGS] build shared libraries [changequote([,
])default=>>AC_ENABLE_SHARED_DEFAULT[]changequote(<<, >>)],
changequote([, ])dnl
it works (there are other syntaxes possible, I'm not particularly for
this one, but I'm really sad that [ and ] have been used to denote
default values in Autoconf's --help. I'd be happy to change this.
AC_HELP_STRING is also very fragile because of [ and ]).
After this, Autoconf distchecks but the tests for autoupdate (you
bet!!!).
In my opinion, this is not the right track. This is only the
beginning of the troubles. In addition, I see no reasons to lose the
ability to trace the uses of `variables':
~ace % ./autoconf -m . --trace AC_LIST_FILES nostromo 10:09
configure.in:44:AC_LIST_FILES
configure.in:44:AC_LIST_FILES
configure.in:44:AC_LIST_FILES:
~ace % ./autoconf -m . --trace AC_LIST_FILES_COMMANDS nostromo 10:10
This gives me information.
So you might think that m4 the C-program is the right place to install
hooks (m4_addhook or something), but I know that René already has
reentrancy issues to solve in m4, so adding such hooks would be a
additional. And think just a second of a hook that messes around with
quotes and syntax etc. Brrrr!
But m4 could provide a better control over the output of the traces,
but then we would depend upon m4 1.5. I don't consider this as wrong
(Autoconf is a maintainer tool!), but I don't think 1.5 will be ready
soon enough.
So we *have* to deal with m4's --trace output. Part of the problem is
that we have to parse balanced [ and ], ( and ) etc. and I must say I
don't know how to do that in sh and Co (I'd be happy that someone
teach me) (well, I don't mean counting them one by one in AWK :).
There's an idea which is really attractive, and I would like to know
what people think about it. Take a look at the raw output from m4:
m4trace:configure.in:36: -1- AC_DEFINE([_ALL_SOURCE])
m4trace:configure.in:37: -1- AC_DEFINE([_POSIX_SOURCE], [1], [Define if you need to in
order for `stat' and other things to
work.])
m4trace:configure.in:37: -1- AC_DEFINE([_POSIX_1_SOURCE], [2], [Define if the system
does not provide POSIX.1 features except
with this defined.])
Don't you see a tool which would parse it extremely easily? Well, I
give you a hint:
s/^m4trace:\([^:]*\):\([^:]*\): -[0-9]*- \([^(]*(\)\(.*\)$/\3[\1], [\2], \4/
See what I mean? Well, OK, here is the result:
AC_DEFINE([configure.in], [36], [_ALL_SOURCE])
AC_DEFINE([configure.in], [37], [_POSIX_SOURCE], [1], [Define if you need to in order
for `stat' and other things to
work.])
AC_DEFINE([configure.in], [37], [_POSIX_1_SOURCE], [2], [Define if the system does not
provide POSIX.1 features except
with this defined.])
See what I mean?
So yes, the solution I propose it to transform m4's tracing output in
order to re-feed m4 with that.
Now if this idea is accepted, the question will be that of the format
of the request. It can be directly the definition in m4,
autoconf --trace AC_SUBST($1:$3)
to ask just for the line number and the variable, separated with a
colon. The fact that we feed this to m4 gives us quite a lot of power
on the format.
Akim
