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