Am Fre, 2001-09-28 um 19.15 schrieb 1001697323: > Hi all, > > I'm wondering about how to organize the header (.h) files on my project. > The structure is like the following: the directory "prodesk", which is > the toplevel directory, contains a subdirectory named "core", and another > one named "include", both hanging from the topdir. > > In my header files, I need to do some #include's of other .h files I've > written. These files are all placed in prodesk/core subdirectory. > I want to put these files when they are installed on > /usr/include/prodesk. And here, the problem arises. > > I include headers from headers like: (for example) > #include <prodesk/string.h> > > As you may notice, there is the "prodesk/" directory preceding the header > file, so this will work when it gets installed. > > But, to solve the include problems because missing files if the package > is not yet installed I've done the following. I've created a subdirectory > in prodesk/include, that is called prodesk itself. So, I try to shadow > the real include's dir layout. > > Then, I've populated that directory with symlinks: > (wherever I am)/prodesk/include/prodesk $ ln -s ../../core/*.h . > > This way, when building the library, it can include the files fine, and > when is installed I guess that it will work fine. > > Do you think this is a "logical" way to do this?? Or this is weird? Well, this is the way imake applied (still applies ?).
IMHO, it is weird, error-prone and hard to maintain :) (No punt intended). What I do in such cases is either to * Apply a similar layout as Guido mentioned. Pros: Simple source-tree layout Cons: You would have to redesign your existing header hierarchy, files are not safe against accidentially includeing private headers from public ones. * Layout your include directory hierarchy as it would be after installation, i.e. put all public headers below include/.. applying the same layout as the final layout would have, eg. include/prodesk/<someheader>.h Pros: Proper separation of public and private headers, safe against accidental inclusion of private headers. Cons: Somewhat more complex source-tree layout. For larger projects and for projects with long development cycles, I personally prefer the second way of doing it, for small project it actually doesn't matter. Just my 0.02 Euros Ralf
