Re: Where to place include files

[Ralf Corsepius]

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