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

[Jeffrey Hutzelman]

--On Thursday, June 24, 2010 01:20:10 PM -0700 Russ Allbery 
<rra@stanford.edu> wrote:

> 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.

Let's be clear.  The problem is _not_ the use of the acinclude.m4 mechanism 
per se.  All we've done there is moved the "main program" out of 
configure.in and put it in acinclude.m4, not out of false modularity but 
because it was the mechanism available to allow us to have a single "main 
program" from which we produce both configure and configure-libafs.

The problem is that the "main program" is a huge mass of spaghetti code, 
rather than being nice and modular.  I assume that's the point you're 
trying to get across.


> 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).

+1

> 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.

No thanks.  I'd much rather have one "main program" than two, even if that 
means conditionalizing some things on which configure script we're 
building, as acinclude.m4 currently does.  I actually believe the current 
split is close to ideal, with configure{,-libafs}.in containing only the 
bits that really _need_ to be in the top level, either because autoconf 
requires that or because not doing so confuses tools.  That includes the 
initialization, autotools version requirements, output files, and of course 
the bits that define the difference, such as OPENAFS_CONFIGURE_LIBAFS.


> 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.

No.  acinclude.m4 should have all of them, and conditionalize which ones 
are included on OPENAFS_CONFIGURE_LIBAFS.  IMHO this is much more 
maintainable.

I also question the premise that configure-libafs shouldn't at least 
recognize every --enable switch defined for OpenAFS.  Users shouldn't have 
to know which switches happen to have an effect on libafs and which don't; 
configure-libafs should not complain about an "unrecognized" switch that in 
fact is valid but happens not to affect libafs.  On the other hand, I would 
be fine with omitting such switches from configure-libafs's help output.


> 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.

If that is the case, then can we have an appropriate AC_REQUIRE in 
configure.ac (and configure-libafs.ac)?


> 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.

I think I'm neutral on this.  The top-level currently contains two 
directories and (after regen.sh is run) 26 files; your proposal adds a 
directory and moves five files into it (the four you named plus 
mkinstalldirs).  That hardly seems worth the effort.

-- Jeff