Re: Discussion about include file location.

Discussion inline...


On Mon, Aug 12, 2002 at 11:07:24PM -0400, Chris Hanson wrote:
>    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.)

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

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

Not a significant change, no, just really naming, but it will avoid 
maintiaining symlinks and an artifical directory structure in the build
tree.

-bill


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