Getting ready to land lots of stuff

Russ Allbery rra at stanford.edu
Sun Jun 4 19:40:22 UTC 2000


Olaf Titz <olaf at bigred.inka.de> writes:

> Why? I hope you don't mean installing config.h on a machine for which it
> wasn't compiled... Other than that, there is only the namespace issue.

Because the namespace issue is a pain to resolve; basically, you have to
rename all of the standard autoconf results like HAVE_FCNTL_H to something
like INN_HAVE_FCNTL_H or you'll conflict left and right with client
programs that also use autoconf.  And doing all that munging is really
annoying and autoconf doesn't provide any built-in way of doing it.

More to the point, though, you shouldn't *need* config.h to use any of
INN's libraries.  All of the non-autoconf stuff (ie, the interesting
things) should be moved to other headers, and the autoconf stuff mostly
controls compliation and isn't needed to use the already compiled
libraries.  The only thing in config.h you need to include the library
headers are the #defines for things like size_t and ssize_t, or to handle
const, if your compiler can't.  I'd rather say that client code needs to
just include those checks in its own configure and include its own
config.h before including INN's headers, which autoconf-using client code
is probably already doing.  (And on modern Unixes, it may not be necessary
even to do that.)

clibrary.h and config.h are really internal headers for INN and not
particularly well-suited for use by programs other than those building as
part of INN, and aren't necessary for accessing any of INN's library
routines.  I'd rather just not install them, and instead install only
those headers needed to access the libraries, and I'm pretty sure that we
can write them in a way that's portable (although assuming ANSI C, but we
decided to do that a while back).

> This strikes me as a bit wrong. If the intention is to install the
> headers so they can be used along with the libs in compiling third-party
> software (as in -I/news/include -L/news/lib) without the source tree,

Right.

> then you have to install _all_ headers needed for compiling. This does
> include the autoconf stuff.

See above for my arguments, although I could well be wrong.

> I also think that if we use an include subdir, we should put _all_
> headers there. libinn.h may be unique namespace-wise, but so is Xlib.h,
> for example. Having both a subdir and toplevel is just as confusing as
> having too many subdirs (what stuff is libstorage and what is libinn?
> You usually need both anyway).

Okay, that's a good point.  I'll plan on doing that (since INN has never
installed its headers before anyway, it's probably not worth worrying
about breaking client programs by moving commonly included header files;
they already had to handle them being in odd places).

> This is long overdue, btw.

Yeah, agreed.

> "bool" is a keyword in C++, so any system or application header which
> defines this must take special precautions anyway. <ncurses.h> is an
> example. Best use an autoconf test to see whether it is already defined.

The ncurses method looks like overkill to me:

#undef TRUE
#undef FALSE
#define CXX_BUILTIN_BOOL 1
#define CXX_TYPE_OF_BOOL int

#if defined(__cplusplus) && CXX_BUILTIN_BOOL
#define TRUE    ((CXX_TYPE_OF_BOOL)true)
#define FALSE   ((CXX_TYPE_OF_BOOL)false)
#else
typedef CXX_TYPE_OF_BOOL bool;
#define TRUE    ((bool)1)
#define FALSE   ((bool)0)
#endif

Those casts should be unnecessary; all of the likely types for bool are
compatible in the range of 0 and 1.  They're also not handling a case that
the Perl way of doing this handles.  Provided that you include ncurses.h
before inn/defines.h, I think the way I'm currently using will work fine
and be compatible:

/* Make available the bool type.  The following macros were taken from the
   Perl source, with some modifications. */
#undef TRUE
#undef FALSE
#define TRUE    (1)
#define FALSE   (0)

/* C++ has a native bool type, and our TRUE and FALSE will work with it. */
#ifdef __cplusplus
# if !HAS_BOOL
#  define HAS_BOOL 1
# endif
#endif

/* The NeXT dynamic loader headers will not build with the bool macro, so
   use an enum instead (which appears to work). */
#if !defined(HAS_BOOL) && (defined(NeXT) || defined(__NeXT__))
# undef FALSE
# undef TRUE
typedef enum bool { FALSE = 0, TRUE = 1 } bool;
# define ENUM_BOOL 1
# if !HAS_BOOL
#  define HAS_BOOL 1
# endif
#endif /* NeXT || __NeXT__ */

#if !HAS_BOOL
# define bool int
# define HAS_BOOL 1
#endif

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



More information about the inn-workers mailing list