[RFC] Short- and medium-term proposal for AC_CHECK_* overhauling

[Bonzini]

What follows is a proposal for rethinking the way AC_CHECK_xxx are implemented,
organized in three parts that respectively:
- reduce configure script size
- make more widespread use of m4 loops/lists
- set up a framework for providing specialized implementations of generic 
feature tests

Part 1 of the proposal applies, more precisely, to AC_CHECK_FUNC, AC_CHECK_TYPE,
AC_CHECK_HEADER, AC_CHECK_DECL, AC_CHECK_PROG and AC_CHECK_TOOL.  It aims at 
creating
shell functions for the body of the test, so that the expansion of the macro is 
along
the lines  of

    _ac_check_func 'strerror'
    if test $ac_cv_func_strerror = yes; then
        ...
    else
        ...
    fi

The potential compatibility problem of this change is that conditional testing 
would
cause more failuers than it does now: Autoconf 2.57 already fails subsequent C 
language
tests if the first AC_CHECK_FUNC was conditionally skipped and not preceded by 
an
unconditional AC_PROG_CC; with this approach, skipping the first AC_CHECK_FUNC
expansion will cause the shell function not to be defined and all other 
AC_CHECK_FUNC
tests to fail miserably.

This can be worked around by providing the shell functions unconditionally as 
part of
AC_PROG_CC and AC_PROG_CXX, for example, but on the other hand this problem can 
also be
put in a positive light.  It is an opportunity to finally document which macros 
can be
expanded conditionally and which cannot; it can be fixed well enough (as far as 
the
Autoconf project is concerned) by appropriate documentation; and the usage of 
shell
functions was long awaited and justified with the size reduction in configure 
scripts,
which I think can be expected to be on the order of 10-15%.

Shell function adoption might be done for other big macros, such as 
AC_CHECK_SIZEOF.

To answer to a possible objection: I know that shell function adoption was said 
to be
scheduled for Autotest at start, but so far I see nothing, not even in CVS, 
even a few
months after Autoconf 2.57 has been released.

Part 2 of the proposal involves AC_CHECK_FUNCS, AC_REPLACE_FUNCS, 
AC_CHECK_TYPES and
AC_CHECK_HEADERS.  These should be converted to use m4 loops instead of shell 
loops,
possibly accepting both parenthesized and space-separated lists, and possibly
deprecating and warning about the latter.  m4 loops, each expanding to a 
separate
invocation of AC_CHECK_FUNC, would expand configure scripts, but not as wildly 
as if
done before part 1, because the shell functions created for part 1 would be 
exploited,
of course.

These two phases can be implemented relatively easily.

Part 3 of the proposal is to implement specialization for the same macros 
involved in
part 1.  This was already done experimentally by Akim a few years ago.  In 
other words,
AC_CHECK_FUNC(alloca, ...) would be made to expand a macro called 
AC_CHECK_FUNC_alloca
instead of invoking the shell function: once this is done, you can rename, for
instance, AC_FUNC_ALLOCA to AC_CHECK_FUNC_alloca and obsolete the former 
together with
all the macros for specific tests.

I put part 3 last because its implementation is made a lot more linear by a more
widespread adoption of m4 loops.  The mechanism would depend only on the 
presence of an
appropriately named functions, and hence would be user-extendable (for example 
by
gnulib); however it would probably be quite controversial whether to actually 
document
it, also because a clean, user-extendable solution would probably imply the 
death of
aclocal. [[[ ping: autolib... :-) ]]]

If parenthesized lists were ever to be made the only possibility, it would 
indeed be
the time to release 3.0; but it might be worthwhile to make this happen 
together with
the completion of part 3, and with the end of the support for Autoconf 1 macro 
names,
at least in my opinion.  And it would be wise to consider the reaction that 
users would
have especially given the cold acceptance of Autoconf 2.5x in the 
not-so-distant past.
For 2.13 users, this would indeed be an excuse to procrastinate further -- 
should
Autoconf developers care about this? or how much?

The relative simplicity (in terms of required implementation effort) and the 
modularity
are the strongest points of this proposal, in my opinion.  The stepwise nature 
should
encourage Autoconf developers to follow the well-defined steps towards the 
goal, also
by keeping the documentation clean and up-to-date.  The facts that each part 
does
provide some tangible benefit, and the possibility of doing at least parts 1 
and 2
without hindering backwards compatibility much, on the other hand, allows users 
to
upgrade step-by-step without having to concentrate all the effort in a single 
time.

Now here is what I am going to do in order to help this proposal to happen.  Of 
course
I'm ready to answer any questions, discuss these ideas and refine them.  I am 
also
going to prototype part 1 with some tests on GNU Smalltalk, which has over a 
megabyte
of configury distributed among four scripts, in a short time (I hope to provide 
results
in a month), and put effort this summer in part 2 and possibly 3.

Regards,

Paolo Bonzini