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

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/19/2010 09:14 PM, Jeremy C. Reed wrote:
> 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>
> 
(snip)
> 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?

err, am i missing something or are these proposals contradictory?

I'm not opposed of having headers in a separate directory (in fact it's
what ldns did), but I'm also not on favour of it :)

But it would still have the problem that #include <bind10/cc/data.h>
wouldn't work. And that one should, I agree that #include <cc/data.h> is
too vague when installed.

And I hate my own hack of symlinks to get include statements right,
which might also create problems for make -j etc.

We could still have them in the same dir if we added bind10 in the path,
right after whatever we decide on as the 'base' for c++ code. But then
we would have even more directories;
src/cpp/lib/bind10/cc/ (or src/lib/cpp/bind10/cc...)

another option could be to remove src altogether and replace that one by
the language;
<base>/cpp/bind10/cc/data.h
<base>/cpp/bind10/cc/data.cc
<base>/python/isc/cc/session.py

(query, should we rename isc to bind10 in the python then for
consistency or the other way around, isc in the cpp part instead of bind10?)

Note that i left out lib/bin here. I'm actually not quite sure if that
needs its own sub-division, or it's own base tree (yes, which can then
contain python and c++ and shellscripts, but that doesn't actually
matter, since the files in there would be used directly; that may be a
bad idea, or not.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuEFCEACgkQ4nZCKsdOncWUtQCg29ZtMYuzdcpt1mavApGghzfF
du4Anj6gMUFH7/LaPyyR3zTQJGRXrqL7
=dG8T
-----END PGP SIGNATURE-----