[OpenAFS-devel] Re: autoconf

[Russ Allbery]

Nathan Neulinger <nneul@umr.edu> writes:

> Why not start out by getting the following autoconf capabilities:

> 	determine the afs systype from the host type determined by autoconf

Or config.guess to be slightly more precise (config.guess is actually
maintained separately from autoconf, although autoconf has linkage for it
and macros that use it).  Yup, that would be a good start.

> 	build in separate source tree - using the autoconf linking of files
> instead of the pre-setup way we have now.
> 	generate a config.h that stuff can start including.

Those sound like good first steps.

We need to figure out what features AFS cares about and is using systypes
to check for and make a list so that we can start writing checks for them.
That would be a great project for someone who isn't that familiar with the
code and with the inner workings of AFS to do; it's more tedious than
really difficult.

Incidentally, I'd recommend starting with autoconf 2.49b, the test release
of the next version of autoconf, on alpha.gnu.org rather than going with
the default autoconf if possible, since 2.50 is supposed to be out fairly
soon now and the internal architecture differences are *huge*.  It's
almost a complete rewrite, so it's worth considering starting with the
latest and greatest rather than something older that we'll then have to
redo down the road.  Particularly since we're just starting.

Down the road, we really want to use libtool (and probably automake,
although I'm not as fond of it), but I think we should tackle that later
as that's a lot harder.

One of the other things that goes hand in hand with autoconf support that
needs to be decided up front is what level of portability we're going to
aim at.  This isn't something you want to just let fall out of what people
do, in my experience; we want to set some sort of standard and not bother
with portability to systems older or stranger than X.  Otherwise, you end
up using a bunch of autoconf tests to try to port to platforms that no one
actually uses or tests on and you make the code unnecessarily complicated
for no real gain.

For INN, we decided to assume ANSI C89 and basic POSIX (so we assumed the
mem* functions were available, <unistd.h> was available, getopt was
available, #elif and string concatenation could be used, <strarg.h> was
available and could be used, and so forth).  I'm personally in favor of
that particular standard, but we could pick some other; it's good to have
some metric to use, though.

(The ANSI C89 question basically comes down to "do we support SunOS's
native compiler."  We didn't quite apply the standard strictly; we do have
portability code to deal with a few pre-ANSI things like <strings.h>
instead of <string.h> specifically for SunOS.  If you apply the above
standard strictly, the code won't compile on SunOS even with gcc, but that
may be what we want to do; it will save work, and Transarc AFS already
doesn't support SunOS.)

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