Discussion about include file location.

   Date: Tue, 13 Aug 2002 10:19:23 -0500
   From: "William J. Mills" <[email protected]>

   > The only problem I see with this is a minor one, in that it makes
   > references to the installed include files non-standard.  That is,
   > using "<FOO.h>" when the file is actually in "/usr/include/beepcore/"
   > fools the programmer into thinking that the files are in
   > "/usr/include/".  Most other references to subdirectories of
   > "/usr/include/" include the subdirectory name in the include
   > statement, e.g. "<sys/stat.h>".  All other things being equal, I'd
   > prefer to use "<beepcore/FOO.h>" references instead.
   > 
   > (Note that I am agnostic on "beepcore/" vs. "beepcore-c/"; I chose the
   > latter because it was more specific.)

   This is the key to the distinction, that the external developer/consumer
   of the beepcore library would use something like <beepcore-c/FOO.h>
   but internally we'd just use "bp_malloc.h".

Well, that's OK for the .c files, but the .h files themselves must
still use the "<beepcore-c/FOO.h>" notation, or they won't work when
installed.  I don't know how to fix that other than by rewriting the
.h files prior to installation.  (Which is what I did in my first
attempt at packaging the software.)  Rewriting seems like an even
uglier hack than building a directory of symlinks.

Then the issue is that the .c files and the .h files are using
different notation to refer to the same include files.  As I said
before, that seems like an unnecessary confusion.  That's why I chose
to make everything uniformly use the "<beepcore-c/FOO.h>" notation.


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31