Re: [swarm-hackers] header directory structure

[Scott Christley]

Well I don't mean to imply that one way is better than the other, they  
are just different and I'm just looking for a solution that  
accommodates both systems, and keeps the end-user source code  
identical across systems.
This doesn't have anything to do with Xcode, its the framework  
architecture, you would have the same issue with plain Makefiles  
trying to compile against a framework.  My understanding is that the  
compiler does some sort of translation so when you give the flag "- 
framework Swarm", it converts
#import <Swarm/DefObject.h>

into the actual path, something like

#import <Swarm.framework/Headers/DefObject.h>

as well handling the linking to the library, plus other runtime things  
like access to resource files.
The one solution I put forth was to re-organize the header directory  
structure for GNU/Linux systems, but if that will be too much churn  
for end-users then the change can be kept internal to Swarm.  This  
other solution means changing Swarm header files (not user  
applications) to have logic to handle the difference directory  
structures, something like this:
#if OPENSTEP
#import <Swarm/DefObject.h>
#else
#import <defobj/DefObject.h>
#endif

The third alternative is for Swarm to not be a framework and just be a  
plain UNIX library, this is possible but its my least favorite because  
it decreases the ease of distribution and usability, essentially one  
of the main reasons the framework architecture was introduced.   
Installation on Mac goes from a simple, drag/drop one file to a well- 
known directory, into needing to write an installation program to put  
all the different files in all the proper directories.
And this is without getting into the whole GUI issues, which when we  
finally resolve by bring Swarm closer to MVC architecture will likely  
break source code anyways because the GUI protocols will be rewritten.


On Jul 6, 2008, at 10:56 PM, Marcus G. Daniels wrote:

> Bill Northcott wrote:
> > I would be very unhappy about this.  I think one needs some  
> > extraordinarily compelling reason to make a change that would break  
> > almost every file of existing Swarm library and model source code.
> Even with Makefile.appl changes to keep code backward compatible on  
> non-Mac Unix, there seems to be the implication that Mac-based  
> models will follow new conventions, and apparently only to make  
> XCode happy.  Thus, models developed on Macs, seem to end up with  
> interface changes that won't be compatible with existing  
> conventions.  Thus, there is an old implicitly obsolete way and a  
> new Mac way, and all existing models fall into the former category.   
> Did I get that right, and if so is there really no way to hook XCode  
> Makefiles to use -I, etc. as Bill says?
> I understand GUI things are a sticky problem, but at least it ought  
> to be possible to keep BatchSwarm code working without  
> modification.  ?
> Marcus
>
>
>
> _______________________________________________
> swarm-hackers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/swarm-hackers