swarm-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [swarm-hackers] header directory structure


From: Scott Christley
Subject: Re: [swarm-hackers] header directory structure
Date: Wed, 09 Jul 2008 10:23:03 -0700


On Jul 8, 2008, at 5:55 PM, Bill Northcott wrote:

On 09/07/2008, at 10:25 AM, Scott Christley wrote:
Within Swarm and Swarm model code we have #include <defobj/ defobj.h> which is found through the '-I /Library/Swarm.framework/ Versions/Current/include' option setup by configure.

Right, which is exactly the problem I'm talking about... #import <Swarm/defobj.h> is not the same as #include <defobj/defobj.h>, so we have two different ways to include in headers, making Swarm apps not source code identical across the two systems. My suggestion was to standardize on #import <Swarm/defobj.h>

Your message seems to have crossed mine in the cloud. My framework layout does not remove the need for a -I option in a Cocoa/framework model build. But we could ship an Xcode template that includes this.

This is just the flip side of the same coin, instead of saying "the rest of the world should be changed to conform to MacOS", we are saying that the Mac world has to conform to Unix conventions. Furthermore the -I option has to be readjusted whenever the framework gets moved to a new location, so you end up throwing away one of the nice features of frameworks.

We actually have more control over this in the Unix world, where people are use to having to deal with include directories and library directories in makefiles, and we provide a Makefile.appl that handles all the Swarm particulars, so we can just roll those changes into Makefile.appl and the user doesn't need to change their code.

To be more explicit, the directory structure could look something like this:

include/Swarm/
        defobj -> ../
        activity -> ../
        collections -> ../
        etc.

then adding a "-I$SWARMHOME/include/Swarm" into Makefile.appl and everything works. My opinion is that this is the less onerous solution.


Perhaps we could remove the need for the -I flag by having the #include within header files be relative. So in defobj.h you would have #include objc/objc.h without the sort of redundant <>. After all objc.h is strictly a private header. This means altering Swarm sources but not users' model code.

This is how I have it right now by using the quotation marks ("") instead of the arrows (<>) but its not a very good solution as it too requires adding -I options to Makefile.appl, and it has a greater potential for name conflicts with other source code packages.

Scott





reply via email to

[Prev in Thread] Current Thread [Next in Thread]