Getting ready to land lots of stuff

Olaf Titz olaf at bigred.inka.de
Sun Jun 4 10:59:41 UTC 2000


> It's generally considered a bad idea to install autoconf-generated header
> files (they often conflict with the autoconf results used by other
> packages, among other reasons), so config.h won't be installed.  That

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.

> means that definitions used by the other header files (as opposed to INN
> code) need to be put into another header file, which I'm planning on
> calling inn/defines.h.  The installed header files will include that, and
> all of the INN core code should include config.h before including any
> other header files (to get the typedefs and so forth).
>
> Header files that won't be installed (like config.h and clibrary.h) but
> which are just used internally by INN can remain at the top level of the
> include directory; it's only header files that should eventually be
> installed that should move.  libinn.h, having a sufficiently specific name
> and being the include file most likely already included by other packages,
> I think can safely also stay at the top level even when installed.

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, then you have to install _all_ headers needed for
compiling. This does include the autoconf stuff.

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).

So what I propose wrt. the include and library directories is to do
the straight way: put _all_ includes in an (one!) include directory
(to be installed as ~news/include/inn or /usr/local/include/inn or
whatever) and put all libs in a lib directory (as done already). The
autoconf-generated include would become <inn/config.h>, which implies
the necessary namespace separation.

This is long overdue, btw. See the c-nocem configure.in why.

> Finally, I've added the code to set up a bool type to the inn/defines.h
> that I've been working with, eventually to replace the use of BOOL in the
> INN source, since we need the lowercase version for Perl anyway and since
> innfeed has been using it for a while.  This will require testing to make
> sure it doesn't conflict with system headers, but it shouldn't.  I find

"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.

Olaf




More information about the inn-workers mailing list