Discussion about include file location.

   Date: Mon, 12 Aug 2002 21:52:30 -0500
   From: "William J. Mills" <[email protected]>

   Not long ago there was discussion about the organization of the
   include files in the source tree and the semi ugly way they were
   specified in the source files.  I'd like to tkae up that discussion
   again for a minute or 3.

   I agree that the way we had been doing it was inelegant, but I am
   not totallly satisfied with the current state of affairs.

   The #include statements should be much cleaner, but I think we
   should make the disticinction between developing in beepcore itself
   and the location of the include files when installed as a
   developers kit.  I would proprose that we change what we are doing
   so that the include files live in their respective directories, and
   use -I directives for building beepcore. The installation can
   install all of the header files, along with the libraries in
   something like $(DESTDIR)/include/beepcore.

   Does this address people's needs?

This is OK, provided that the assumption will be that the include
statement is of the form

	#include <FOO.h>

rather than

	#include <beepcore/FOO.h>

Otherwise, it's not possible to achieve this using -I statements,
unless the include files are moved to "beepcore/" subdirectories.

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

I am a little curious though -- how does this change the way the code
is written or thought about?  It seems as though you are suggesting an
alternate mechanism for implementing the naming, rather than a
structural change.

Chris


-------------------------------------------------------
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