Re: converting netkit to autoconf?

[Russ Allbery]

Bruce Korb <address@hidden> writes:

> Autoconf is about two different purposes.  First, the developer needs to
> know what features are present or lacking on a target system; then the
> ultimate builder uses its facilities to tell it what to enable or not
> and where to put the results.  That's two interfaces for one product.

Or, to put that another way, Autoconf both probes system capabilities
automatically and supports manual configure-time options.

For the former, you need some way of overriding when Autoconf guesses
wrong.  For the latter, you don't want Autoconf guessing at all (but you
do need some way of telling it what to do from the command line, since
those of us with automated build systems find this *much* easier to deal
with than maintaining patches to configuration files the user is supposed
to "edit").

These should probably be split into two separate tools, frankly.

> Why am I having this sense of deja vu?
> http://sc-archive.codesourcery.com/sc_config

These results were very depressing.  None of them tackled what I consider
to be the major problem, namely a coherent and simple way to write probes.

BuildConf is basically Autoconf plus Automake, which is useful but not
what I want and which isn't going to be any easier to write probes in than
Autoconf is now.  It also brings in the whole build system problem, which
is a different issue entirely.  The build system problem needs solving in
a more comprehensive way by again providing a higher-level interface where
operations like "build a shared library" are expressable notions in the
language that the programmer is using.  Again, Automake attempts to get
there, but its reliance on portable make as the foundation results in
serious limitations.

ConfBase and Tan appear to be all about organizing the presentation of the
probes rather than writing the probes itself.  Not interesting to me.

SapCat is the only one of the group that really seemed to be heading the
direction I'm interested in seeing things go, but it again is also trying
to solve the build problem, plus when you get down to the bit about how to
write tests, it again looks basically like Autoconf.

I don't think there's any way to get around the fact that in order to have
a really easy configuration probe language, you need an underlying tool
with intimate knowledge of the programming languages and environments
being probed.  You can't expect the user to tell the tool how to check if
a function exists; the probe language has to already know how.  The most
that's really acceptable is to ask the programmer to provide a test case
that fails, and the interface for doing that has to be as clean as
possible and involve as little distortion of the original test code as
possible.

Maybe the problem as I'm thinking of it is just too hard to really fully
solve.

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