The care and feeding of autoconf

Russ Allbery rra at
Tue Sep 7 19:30:12 UTC 1999

There are several things that are currently rather odd and hackish about
the build system that I'd like to clean up.  In the process, it would be
nice to work out some consistent guidelines for what data types we want to

My goal with autoconf and standard data types is going to be, I think, to
try to make it possible to use pure ANSI C data types everywhere and for
autoconf to fix them so they work with preprocessor magic where needed.
In other words, you should be able to just use uid_t, size_t, const,
sig_atomic_t, and the like, and if they're not available, they should be
#define'd or typedef'd to something appropriate in config.h for you.  So
as long as you include config.h, everything just works.

This means that I'd like to make UID_T, GID_T, etc. slowly go away in
favor of just using the "correct" data types and letting configure take
care of it.

The main place where this *doesn't* work is with void.  That's because
there really is no single substitute for a declaration like:

        void function (void);

If the (void) declaration isn't allowed, you want void to disappear
completely, but if void isn't recognized as a return type, you want to
change it to int or something similar.  And void * should probably turn
into char *.

Shall we just assume that we have void and not try to work around it?  Or
do we want to try to keep the current mechanisms #defines like ALIGNPTR
and FUNCTION?  The problem with the latter is that new contributors may
not use them or realize what they're for, and they're harder to read.

(I think we can probably just avoid declarations of the style (void) and
just use () instead; the drawbacks aren't that large, and for some reason
I have the feeling that (void) declarations are somewhat newer... but that
may be totally wrong.)

The other big problem currently is that the config files are a rat's nest.
We have config.h, clibrary.h, configdata.h, macros.h, and libinn.h, all of
which are included in pretty much everything, but some of which have lots
of old cruft.  (Plus lots of random legacy subst stuff.)  It's very
unclear what each of these is supposed to define or not define.

What I'd like to try to do is this:

 * Merge config.h and configdata.h, and put in that file (called config.h)
   all data that's dynamically determined at configure time.  Anything
   that's static and unchanging should be moved somewhere else.  All of
   the stuff that is no longer used anywhere in the code base should be

 * Write an acconfig.h and get back to the point where can be
   automatically generated by autoheader.  Currently, it can't be, and
   there is a lot of magic that autoheader would generate to make things
   that configure is finding out work great that isn't currently there;
   for example, we're testing for const, uid_t, gid_t, etc. and not doing
   anything with that information.

 * Clearly define the role of clibrary.h.  What clibrary.h should be, if I
   understand the concept correctly, is the equivalent of:

        #include <stdio.h>
        #include <sys/types.h>
        #include <sys/time.h>
        #include <stdlib.h>
        #include <unistd.h>
        #include <limits.h>

   with whatever happens to be broken or missing on a given platform also
   worked out and included.  I'd like to make it that, and at the same
   time fix the way header inclusion is handled.  We currently don't use
   the results of STDC_HEADERS the way the autoconf manual says to.
   Instead, we still prefer things like memory.h over stdlib.h, even if
   STDC_HEADERS says that stdlib.h has malloc() and free().  That makes
   life unnecessarily complicated and forces us to check specially for
   platforms like Digital Unix.

 * Roll macros.h into libinn.h, since I think they serve fundamentally the
   same purpose, things like NEW() and COPY() being essentially part of
   the INN library that all of its programs use.

 * Start cleaning up the includes of the various other source files in
   INN, so that if they include clibrary.h, they *don't* also include
   unistd.h, etc.

Does this sound reasonable for me to start working on as I find the time?
Any objections to any of this?

Russ Allbery (rra at         <URL:>

More information about the inn-workers mailing list