[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:
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
- Re: [swarm-hackers] header directory structure, (continued)
- Re: [swarm-hackers] header directory structure, Scott Christley, 2008/07/07
- Re: [swarm-hackers] header directory structure, Bill Northcott, 2008/07/07
- Re: [swarm-hackers] header directory structure, Scott Christley, 2008/07/07
- Re: [swarm-hackers] header directory structure, Marcus G. Daniels, 2008/07/07
- Re: [swarm-hackers] header directory structure, Bill Northcott, 2008/07/07
- Re: [swarm-hackers] header directory structure, Scott Christley, 2008/07/08
- Re: [swarm-hackers] header directory structure, Bill Northcott, 2008/07/08
- Re: [swarm-hackers] header directory structure, Scott Christley, 2008/07/08
- Re: [swarm-hackers] header directory structure, Bill Northcott, 2008/07/08
- Re: [swarm-hackers] header directory structure, Scott Christley, 2008/07/09
- Re: [swarm-hackers] header directory structure,
Bill Northcott <=
- Re: [swarm-hackers] header directory structure, Scott Christley, 2008/07/10
- Re: [swarm-hackers] header directory structure, Bill Northcott, 2008/07/10
- Re: [swarm-hackers] header directory structure, Bill Northcott, 2008/07/08