[OpenAFS-devel] Future direction for Autoconf macro handling in OpenAFS

[Russ Allbery]

Moving this here from Gerrit.  This is a proposal, not a finalized
position.  Please review and comment, and then we'll take some form of
this and put it into README.DEVEL.

One of the things that makes OpenAFS's configure script difficult to
maintain right now is the giant acinclude.m4 file, which is the equivalent
of putting all the code of a complicated module in a single
function. Breaking code into separate and easily digestible functions is
as important for Autoconf as it is for C.

The philosophy that I'd prefer to move towards is instead: any Autoconf
macro that's reasonably generic should be kept separate in src/cf, as
should major chunks of reasonably independent code (such as the collection
of Linux tests, which could stand to be broken up further by area of
functionality).

configure.in should contain the invocations of the generic macros that are
defined in src/cf files which are used for building the whole tree, and
more generic tests that don't make sense as coherent separate units, like
the various probes for standard library functionality.

acinclude.m4 should only contain those things that are relevant to both
configure-libafs and configure. Much of its current content should move to
configure.in. And for anything that makes sense to wrap in a coherent
macro with a well-defined interface (sysname probing is, I suspect, a good
example) should move into src/cf as its own *.m4 file.

It's nice to have all the --enable/--disable (as opposed to --with) flags
collected in one place so that they can be reviewed, but I think we're
going to need to have two lists of --enable definitions, one that applies
to both configure and configure-libafs and one that applies only to
configure.  Otherwise, we're going to have all the --enable flags into
configure-libafs like we do now, including ones that make no sense there,
like --enable-supergroups.

acinclude.m4 should have the (much shorter) list of --enable flags that
apply to both userspace and the kernel module or only to the kernel
module, and configure.in should have all the rest of them.

I also would like to, fairly soon and before we start moving more stuff
into it so that we don't have as many outstanding patches mentioning it,
rename configure.in to configure.ac to follow current Autoconf
recommendations.  We already require a version of Autoconf that looks for
that input file by default.

Finally, now that we require a new enough version of Autoconf, I'd like to
propose adding:

    AC_CONFIG_AUX_DIR([build-aux])

so that all the supporting build files like config.guess, config.status,
install-sh, missing, etc., are put into a separate build-aux directory
instead of into the top level of the tree.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>