where are the headers?

[Ronald Aigner]

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

Hi Alan,

Alan Grimes wrote on 19.07.2006 04:11 this:
> There's a great deal to be said against the design choices above.
Then let me make a point for those design choices.

> 1. Creating include directories in this kind of automated fassion
> obfuscates where the relevant files are. As a counterexample, the Minix
> source tree placess all PUBLIC header files in "./src/include" while
> keeping PRIVATE header files in "./src/kernel". It is hard to find fault
> with Minix's design choices because it is trivial to find exactly which
> headers your driver needs and know which ones it _SHOULD_ be using.
As we see each "package" as a own piece of software, each has a PUBLIC
header file directory, for example, l4/pkg/dm_phys/include and PRIVATE
header files do appear either in the source directory or in private
include directories, for example, l4/pkg/dm_phys/server/include.

> 2. the "pkg" directory, possibly overcrowded on my system because I was
> essentially grabbing stuff at random, is far too flat for its own good.
You might be right about that. It just grew and grew and grew and with
cvs as repository it's just a pain in the ass to restructure the
directory layout.

> As a counterexample, Minix divides its sources into "commands",
> "drivers", "Servers", and "Lib". This organization is indispensible to
> someone trying to learn the system.
Most of the packages provided are services, which consist of a server
running in its own address space (so you might want to place that into
"Servers") and a client-library (which you probably would put into
"Lib"). We also have server that are different implementations of the
same interface, so you would probably have to have directories
"Interfaces" and "Server- or Internal-libs" as well. Now the writer of
one piece of software would have to maintain sources in three to five
different directories. That's why we decided to group the source of one
piece of software into one package.

> 3. Libraries and headers from the varrious packages should not be mixed
> except in the installed OS. Necessary headers should be -I'd into the build.
Let's say you have a types.h in package foo and a types.h in package
bar. How do you differentiate them if you just -I their include paths.
Now that's where the separate include path comes into play. Our make
magic installs the headers of each package into include/l4/<package
name>/. So foo/types.h and bar/types.h can be distinguished using the
path in the #include statement. Otherwise we would have to either call
them foo_types.h or bar_types.h or create subdirs in each package's
include path. (Now explain that part to a novice ;) ).

> 4. Automake, though it is a nightmare, actually does seem to help things
> on the user side. Since my Minix installation already works much much
> better than my Linux installation ever did, I'd like to be able to try
> to build L4 on it. =P -- Okay, not very realistic...
You might be right about using automake. If you volounteer to migrate
our build system to using automake we will give you reasonable credit on
the webpages and READMEs.

> In general, Minix is a very well laid-out system. I'd highly reccomend
> you look at how they laid out the tree and build system; But don't try
> to make L4 as cripled as Minix currently is!!! =P Users can't even use
> simple IPC on Minix!!! =((( -- hence my renewed interest in L4.
We try! I like to use one of my favourite open source citations here:
"Hey, it's open source. If you like to see it improved, go ahead!" (No
offense!)

Regards, Ron.
- --
Mit freundlichen Gruessen / with regards
ra3 @ inf.tu-dresden.de
http://os.inf.tu-dresden.de/~ra3/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEve66vCdOf9l7ipgRAn3fAJ95PqXOO0l1HTcqorjTAX4RAqgMSACdFs37
oTZrSYeh20lmpryGAU9J7w4=
=wUFn
-----END PGP SIGNATURE-----