Re: [swarm-hackers] header directory structure

[Bill Northcott]

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.
In my scheme the source code #import<Swarm/DefObject.h> and #import  
<defobj/DefObject.h> would produce the same result.  So code can be  
written in old Swarm/UNIX style or Cocoa/AppKit style.  I cannot see a  
need to break all the exisiting code.
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.
> > Any thoughts about the symlinks under /usr/local.  Several packages  
> > including Tcl/Tk use them on MacOS.
> I'm not familiar with what the issue is here, are you talking about  
> Swarm binaries that go into /usr/local, or binaries from other tools  
> that Swarm needs to use?
The symlinks are purely to avoid needing the alter PATH variables and  
such like.  So the tools in the Swarm bin folder would be symlinked  
from /usr/local/bin
Cheers
Bill