[bind10-dev] use of installed headers versus headers from tree; naming of include headers

[Jeremy C. Reed]

At some time in the future, we planned to be able to ship components 
individually. In that case, now, we should structure the tree so it can 
potentially use already installed headers.

The include references we use now maybe should represent what we want to 
use in the long run.

For example src/bin/auth (from branches/each-ds) uses:

#include <cc/data.h>
#include <cc/session.h>
#include <auth/data_source_static.h>
#include <auth/data_source_sqlite3.h>
#include <dns/buffer.h>
#include <dns/messagerenderer.h>
#include <dns/name.h>
#include <dns/question.h>
#include <dns/rrset.h>
#include <dns/rrttl.h>
#include <dns/message.h>
#include <config/ccsession.h>

Now "dns" I guess makes sense. But "auth" and "config" do not. They are 
too vague. (I keep thinking lib/auth is for authorization to configure 
and not authoritative.)

Maybe should install like X.org does or be used like Boost. For 
example:

Xorg ships software as standalone packages (tarballs), but they provide 
headers in standard tree, such as: libX11, libXau, libXdmcp, libXpm, 
libXt, xproto and others all install headers to include/X11/foo.h or 
include/X11/foo/bar.h and non-Xorg users of them use #include 
<X11/foo.h> or #include <X11/foo/bar.h>. As a specific example, 
vnc_unixsrc's source code vncviewer/vncviewer.h uses #include 
<X11/Xmu/StdSel.h>.

It is important to note invidual X.org components need their 
dependencies installed first -- you can't build everything at once using 
headers from the git source tree.

So my suggestion is to use top level include directory name like:

#include <bind10/cc/data.h>
#include <bind10/auth/data_source_static.h>
#include <bind10/config/ccsession.h>

or

#include <isc/cc/data.h>
#include <isc/auth/data_source_static.h>
#include <isc/config/ccsession.h>

or

#include <isc/bind10/cc/data.h>
#include <isc/bind10/auth/data_source_static.h>
#include <isc/bind10/config/ccsession.h>

Maybe also for libdns headers.

Currently nothing in bind10 installs include headers though, so maybe 
this doesn't matter yet.

This gets back to the point of how the files are kept in the source tree 
and referenced from the source tree too (as we have discussed many times 
now in regarding to restructuring source tree).

BIND 9 source is like:

bin/FOO/include/FOO/*h
bin/confgen/include/confgen
bin/dig/include/dig
bin/named/include/named/*h
bin/rndc/include/rndc/*.h
(bin/pkcs11/include/*h is different)

The above headers are not installed, but used by this source only.

lib/FOO/include/FOO/*h
lib/bind9/include/bind9/*h
lib/dns/include/dns/*h
lib/dns/include/dst/*.h  -- that one doesn't match up dns != dst
lib/irs/include/irs/*.h
lib/isc/include/isc/*.h
lib/isccc/include/isccc/*h
lib/isccfg/include/isccfg/*h
lib/lwres/include/lwres/*h
lib/tests/include/tests/*h

These are installed (except tests) and installed like:

include/bind9/*h
include/dns/*h
include/dst/*h
include/isc/*h
include/isccc/*h
include/isccfg/*h
include/lwres/*h

Since we want to build everything from our source tree and also want to 
be able (in the future) be able to build somethings using installed 
headers, maybe we should keep the public to-be-installed headers in 
subdirectories like:

src/lib/libauth/include/auth/data_source_static.h

src/lib/libcc/include/cc/data.h

src/lib/libdns/include/dns/buffer.h

src/lib/libcfgclient/include/config/ccsession.h

(Notice the new naming scheme above doesn't include the language. I 
wrote another email about this but never sent yet as realized we have 
these header problems anyways.)

Any thoughts on this?