Re: [swarm-hackers] header directory structure

[Bill Northcott]

On 10/07/2008, at 3:23 AM, Scott Christley wrote:
> > > 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.

I am sure there are plenty of frameworks that would not take kindly to  
being dragged around, particularly if they, like Swarm contain more  
than one shared library, which are linked to each other.  We cannot  
get away from that if we support Java, because the jni library has to  
be .jnilib.  One can allow the users a choice of install location and  
set up the install_name and build paths using a post install script in  
the package.

> To be more explicit, the directory structure could look something  
> like this:
>
> include/Swarm/
>         defobj -> ../
>         activity -> ../
>         collections -> ../
>         etc.

Is that inside the framework?  If so, how is it symlinked for Xcode?
> then adding a "-I$SWARMHOME/include/Swarm" into Makefile.appl and  
> everything works.  My opinion is that this is the less onerous  
> solution.

Perhaps I still being thick, but I don't get the need for the Swarm  
directory in the hierarchy.
> > 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.

Surely the quoted name has less chance of conflict, because given the  
current pwd it is an absolute path not requiring any searching.

Cheers
Bill