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

[Russ Allbery]

Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> 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.

Yes, exactly.

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

I think it's confusing to put things into acinclude.m4 that are only used
by configure.in.  This is unlike the way nearly every other free software
program using Autoconf uses its configure.ac file and is unnecessarily
confusing for contributors.

Of course, *most* of the material in acinclude.m4 should be moved into
separate macro files in src/cf/*.m4, not to configure.in, so in the end
what we want may be fairly similar.

> 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 don't think I agree with the maintainability of this approach.  The
conditionals make the code harder to read, and conditionals that can be
avoided by simply putting the code in the correct location in the first
place should be avoided, IMO.

> 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'm not sure that's even possible.  Autoconf documents HELP-STRING as a
mandatory argument, and there's no documented way to suppress it if the
option is to be recognized.  I don't want to use undocumented techniques
to do this, particularly since I don't see any strong reason to avoid
people getting unrecognized flag warnings when using userspace-only flags
with configure-libafs.  They're only warnings.

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

We already do.

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

The top level currently contains three directories, eight documentation
files the user should pay attention to, two scripts a user runs (regen.sh
and configure), ten build system files for a regular build, and four build
system files to support make libafs_tree.  We would be moving half the
build system support files the user doesn't care about to a subdirectory,
or roughly a third of the "noise" in the top-level directory from the
user's perspective.

We could make more progress on getting rid of clutter if we wanted.  None
of the libafs support files really need to be in the top level directory,
since they're not invoked from there.  They could be moved elsewhere
without causing any harm.

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