Re: converting netkit to autoconf?

[Russ Allbery]

Tom Tromey <address@hidden> writes:

> First, I don't think they are really separable.  Some changes affect
> both the configuration and the build (e.g., add a probe for a function
> -- you'll change configure, config.h, and presumably some source files).

Well, that doesn't really change both the configuration and the build;
that just changes the configuration and some source files.  Normally, when
I modify configure.in, I don't have to change makefiles at all, just the
source code.  (Or I only modify makefiles, not the source.)

That being said, I think there are definite advantages to integrating the
dependencies of the probes and the running of the probes with the rest of
the build for the reasons you describe below, namely parallelization.

> Second, I think in many cases it would be more maintainable to have
> configury in the same files as the build.  The current situation is less
> maintainable because some choices are made in configure.in and then used
> in Makefile.am, leading to a lot of to-and-fro reading when trying to
> figure out what is going on.

Hm, yeah, there's something to be said for that.  Well, I think we need a
high-level language to describe builds as much as we need a high-level
language to describe configuration.  make is really only a dependency tree
management system, which is nice but is rather too low level to be of a
lot of help.  A good build system should understand the sorts of things
that libtool understands (not to mention understanding subdirectories so
that you don't have to use recursion, understanding how to install files,
and so forth).

Whether, once you have a high-level configuration system and a high-level
build system it makes sense to combine the two is something I'm not sure
about.  Both projects seem more easily approached in isolation, though.

> I'm very curious to hear your ideas on how to express probes more
> clearly; the more specific the better.  I've been thinking about this
> area a lot lately, but I've never considered that Autoconf's method for
> expressing tests might be a hindrance.  Personally I've always found the
> quoting off-putting but bearable.  Would it suffice to have a more
> reasonable programming language (say, Python/Perl/Ruby/Scheme/[insert
> your fave here], instead of m4+sh) with more reasonable quoting rules?

I really don't like the idea of any non-trivial code being quoted at all.
I suppose that if people really want to do that, they can, but for the
dozen or so non-trivial probe programs in INN's configure.in, I'd much
rather maintain them as separate files, like all the other C code in INN,
and not worry about quoting at all.

I found Dan Bernstein's method of doing probes for his packages rather
elegant in its simplicity; he just builds them like any other program,
writes them so that they generate header files, includes those header
files where appropriate, and lets make handle all the dependencies.  I
don't think that scales very well in a few different ways, but something
closer to that than what we have now would be better, I think.

Autoconf is generally moving in the right direction, and having the same
sort of high-level constructs that Autoconf has is the right approach, I
think.  The things that bother me about Autoconf are the ongoing fights
against M4 quoting, the difficulty of writing a brand new test (requiring
dropping back to C and shell with a mess of nasty quoting and a ton of
restrictive shell coding requirements), and an implementation language
that I think is probably discouraging people from contributing more.
Something written in a more reasonable programming language would probably
help with that; Python is likely the right choice at present, I think, if
for no other reason than while Perl is fast to write code in, writing
maintainable Perl code requires a lot of discipline.

The other thing that I really do think should happen is that the
configuration system needs to be well-integrated with a library of
portability routines, and with better documentation of exactly what the
tests are intended to do.  There are some tests in Autoconf
(AC_FUNC_GETLOADAVG is one of favorite examples) where the test is
essentially worthless to someone who isn't either using a specific
replacement routine or knows quite a lot about how to reimplement that
function.

-- 
Russ Allbery (address@hidden)             <http://www.eyrie.org/~eagle/>