swarm-hackers
[Top][All Lists]
Advanced

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

Re: [swarm-hackers] header directory structure


From: Scott Christley
Subject: Re: [swarm-hackers] header directory structure
Date: Mon, 07 Jul 2008 00:28:56 -0700

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





reply via email to

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