[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RFC] Short- and medium-term proposal for AC_CHECK_* overhauling
From: |
Bonzini |
Subject: |
[RFC] Short- and medium-term proposal for AC_CHECK_* overhauling |
Date: |
Wed, 30 Apr 2003 19:46:40 +0200 |
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
- [RFC] Short- and medium-term proposal for AC_CHECK_* overhauling,
Bonzini <=