[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: Thu, 10 Jul 2008 16:56:01 +1000

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:

        defobj -> ../
        activity -> ../
        collections -> ../

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.


reply via email to

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