Re: Writing GNU-Step compatible Cocoa
Re: Writing GNU-Step compatible Cocoa
- Subject: Re: Writing GNU-Step compatible Cocoa
- From: John Engelhart <email@hidden>
- Date: Sun, 9 Dec 2007 18:11:11 -0500
On Dec 9, 2007, at 7:26 AM, Tommy Nordgren wrote:
What Foundation and AppKit classes can I use for a Cocoa based open
source project, if
I want it to easily ported to GnuStep?
The GNUstep documentation for their classes is your best bet. Barring
that, the source is available as well, so a quick grep of the
appropriate header and source files will probably tell you what you
need to know. Be on the look out for stubbed, do-nothing methods that
are often included, usually in AppKit, to ease porting efforts but may
effect functionality you require (e.g., attributed string tooltips
that might not actually provide tooltips). GNUstep also tends to
progress more incrementally, whereas Cocoa tends to make one big leap
(10.4 -> 10.5).
You might want to take a look at my RegexKit project, http://regexkit.sourceforge.net/
I'm not a GNUstep expert, not even remotely, but I choose to
include GNUstep as a target as a gesture of goodwill and as a
debugging aid: being able to compile on platforms other than mac/cocoa
tends to smoke out portability issues and obscure bugs, making for
higher quality code. The same can be said for targeting an
independent implementation of Foundation. I also happen to target
Core Foundation, and I figure if the unit tests can pass when using
Core Foundation, Cocoa's Foundation, and GNUstep's Foundation on a
different architecture, OS, and compiler, there's probably less bugs.
From the RegexKit title, it should be obvious that the framework
deals with regular expressions. That said, it should be obvious that
I only use Foundation, no AppKit (except for some minor things, like
adding a tooltip to an attributed string 'pretty' error message).
That said, there's only a few cases off the top of my head where I've
had to explicitly do Cocoa / GNUstep #ifdef'd code: NSNumberFormatter
differences (10.4 greatly expanded cocoa's NSNumberFormatter) and an
observed objc runtime +initilize behavior difference in class
categories. Those are the big ones that stick out in terms of API
mismatches, so in other words, I've found the Foundation portion to be
practically identical for my needs.
I've managed to hide a lot of other, smaller differences behind pre-
processor macros. I #defined my own NSInteger equivalent, RKInteger,
which just maps to the appropriate native equivalent. The need to run
on 10.4 provided the backbone of NSGarbageCollector compatibility: the
primary class checks to see if the NSGarbageCollector is available and
if GC is enabled and sets a global variable that isn't exported from
the framework on the status. Under GNUstep, NSGarbageCollector is
never available, so there is a #if conditional that either creates an
'extern int gc_status' like variable, or '#defines gc_status 0'. This
causes the conditional statements that need to take different actions
based on whether or not GC is active to become static, and the
compiler optimization pass will simply eliminate the alternative that
will never be executed. There's also some macros for handling
retain / release / autorelease and malloc / free (so
NSAllocateCollectable can be conditionally used, if appropriate),
along with a conditional memmove (cocoa's GC requires a special GC
aware memmove be called). The details of what happen are hidden
behind a RK_MACRO(), which are used as if you were programming for
just the retain / release methodology, substantially cleaning up code
(no big #if blocks littering the source for all the different
scenarios).
In short, you might find a few nuggets here and there for dealing with
Cocoa / GNUstep compatibility, but overall I've found adding, and
keeping, GNUstep compatibility to be a non-issue. Come to think of
it, I've only had two real problems: Writing a GNUstep Makefile, which
seems to be completely undocumented, and finding a version of OCUnit
that was old enough to compile on another platform. I had to add some
macro wrappers because STAssert* and friends are later additions, and
everything switched to @try / @catch, and I wasn't interested in back
porting. Even the objc runtime has been a non-issue for my needs.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden