[Biococoa-dev] GNUStep Compatibility

John Timmer jtimmer at bellatlantic.net
Wed Sep 8 12:20:39 EDT 2004

I looked over the GNUstep site, and they do have a compiler directive
(#ifndef GNUSTEP) that they specifically recommend for avoiding problems
like this.  Helpfully, it was part of an FAQ that pointed out a fundamental
problem that's going to be significant going forward - using Xcode for
development will automatically include Cocoa/Cocoa.h, and THAT ALONE is
incompatible with GNUstep.  To keep things GNUstep compatible, we're going
to have to go back and edit pretty much all of the source code we've made
recently in order to ifndef every set of import statements, and we have to
be very careful going forward.

Given all this, I think it might be valuable to have someone sign up to the
GNUstep-dev mailing list and hash out some of the issues.  They may have
some specific thoughts on cross-platform optimizations.  If nobody else
volunteers, I guess I'll wind up doing it, since I'm the one who's caused
the problem anyway.

Incidentally, I've only optimized existing methods so far, so it should be
relatively simple (if extremely tedious) to go back in the CVS history,
figure out the differences, and place the previous ObjC only method back
within the appropriate compiler directives.

My optimistic thought is that this is going to be very painful right now,
but if we figure out a system soon, maintaining compatibility going forward
might not be that bad.  My fear is that Apple's Xcode updates will make it
harder.  To me, the decision seems to be about whether it's worth losing
some PR and academic credibility in order to provide something to a
community that's unlikely to care. I'm not entirely sure where I stand on
that issue.


> Now we're starting to talk about the real thing, we need a PR person
> ;-) Again, for me the only reason to stay GNUStep compatible is a
> marketing technical one. The question would be to John and Koen, how
> much work would it be to either optimize without CF usage, or optimize
> only on our platform (probably using compiler tricks to switch between
> with or without optimization)?
> I do have noticed indeed that without the "on-multiple-platform"
> argument it's often hard to sell a Cocoa framework to the mass or get
> articles/sponsorships...
> Alex
> Op 8-sep-04 om 9:18 heeft Peter Schols het volgende geschreven:
>> Hi Alex, Jim and others,
>> Last year, we have tried to submit an application note about BC to
>> Bioinformatics. The application note did not get accepted, mainly
>> because the only reviewer (!) was a Mac-hater. Bioinformatics only
>> accepts application notes about open-source software that runs on as
>> much platforms as possible (mostly Java or C apps). That's the reason
>> why we emphasized the cross-platform possibilities with our BC code. I
>> think we should still try to submit an application note to BI (or
>> another journal) within a few months, when we have a stable BC
>> release. If the list agrees with that, compatibility with GNUstep
>> would be necessary. On the other hand, I love many of the recent
>> additions: bindings in Panther, core data in Tiger and I guess many of
>> you like them too.... it will take the GNUstep team quite some time to
>> integrate them, if they appear at all...
>> Whether we should keep our framework below its own speed and
>> possibilities just for the sake of GNUstep compatibility is a hard
>> question. I'd be interested in your opinions.

This mind intentionally left blank

More information about the Biococoa-dev mailing list