[Top][All Lists]

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

Re: [swarm-hackers] header directory structure

From: Bill Northcott
Subject: Re: [swarm-hackers] header directory structure
Date: Wed, 9 Jul 2008 10:55:23 +1000

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


reply via email to

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