OGo currently uses the libFoundation library as its basis. libFoundation, like Apple Cocoa Foundation and the GNUstep-Base library more or less follow and extend the so called "OpenStep API Standard" and are therefore provide source code portability.
Notably gnustep-make supports a mixed compilation using so called "library combos".

Unfortunately all three of the Foundation libraries contain non standard additions and OGo makes use of some of libFoundation's extensions. A lot of those extensions were once available in the so called "FoundationExt" library, which we consider deprecated today. Instead the differences should be catched in the skyrix-core/NGExtensions library.
Because of those issues the MacOSX port to Cocoa is pretty similiar to the GNUstep port.

Finally, we need a reason for the port ;-) The major advantages of gnustep-base over libFoundation are:

There is no specific organizer for MacOSX ports yet. For now, just contact Marcus Müller, he'll forward you to the appropriate list/person ;-)
Another very active person who already provided several patches is Filip Van Raemdonck.
People currently involved:

In general you can follow the usual source code compilation instructions. I configured gnustep-base that way:

./configure --prefix=$HOME/GSRoot \
--without-system-root \
--with-local-root=$HOME/GSRoot \
--with-network-root=$HOME/GSRoot

But of course it should work with any configuration ;-)

Fixed a major issue with handling of bool numbers in the PostgreSQL adaptor, fixed German language .string files (which require a trailing ';' on gstep-base).
A lot things work now (but some don't ;-).

Tried compilation of current head:
skyrix-xml: clean compile.
skyrix-core: only some warnings on a type mismatch for +initialize (due to Object), can't be worked around?
skyrix-sope: some type mismatch warning on -charValue.
Database: clean compile.
Logic: a few commands must be fully ported, otherwise clean compile.
DocumentAPI: some minor warnings.
WebUI: Contacts - clean compile, Scheduler - some warnings, Mailer - clean compile, JobUI - clean compile. Other stuff may show warnings, but everything compiles

But does it work? Nope, not yet (SOPE itself should work!). Fails with:

2004-06-21 23:00:24.620 OpenGroupware[17324] ERROR(-[NGBundleManager bundleWithPath:]): could not create bundle for path: '/home/donald/GNUstep/Libraries'
2004-06-21 23:00:25.542 OpenGroupware[17324] |OpenGroupware| CTI Dialers: ./OpenGroupware.woa/OpenGroupware: Uncaught exception NSInvalidArgumentException, reason: Tried to add nil value to dictionary
Aborted

So something seems to be broken with the NGBundleManager. In addition something is broken wrt to NSURL.
In addition you might need to set export GNUSTEP_STRING_ENCODING=NSISOLatin1StringEncoding because OGo property lists are stores in ISO-Latin-1 and fail to load with the UTF-8 encoding which gstep-base defaults to.

A *lot* of compilation warnings are fixed in the whole OGo repository - it now compiles without major issues. In addition some tweaks to NGBundleManager are applied to work properly with gstep-base.
Unfortunately OGo still does not properly run with gstep-base due to some issues related to EOSQLQualifier parsing.

Fixed various compilation warnings and cleaned up gnustep-base compilation. As expected things seem to be fluent after the Cocoa port which also uses a recent gnustep-make package.

OK, something is happening again ;-) Nicola and some other people are providing patches, mostly makefile stuff, which are applied to some extend. We'll probably use the "official" gstep-make sources for the "official" Debian packages, so this is pushed. Nicola also would like to use gstep-base for the "official" Debian packages, which may push that porting front as well ;-)

The GNUstep porting project is currently stalled. OGo should compile with the most recent gstep-make, a side-effect of our MacOSX porting efforts which use the makefiles.

gnustep@opengroupware.org

Helge needs to summarize more issues he knows about an OGo GNUstep port ...

When first patches arrived, some issues came up ;-)

gstep-make defines | import-vs-include | do-not-break-lF-or-Cocoa | -indexOfString: | math.h

Using a define like:

#ifdef GNUSTEP
...
#endif

makes no sense in the OGo context. As Nicola pointed out: "GNUSTEP really means *-gnu-gnu, while GNUSTEP_BASE_LIBRARY means *-gnu-*". OGo has no dependency on GNUstep-GUI, so please always use:

#if GNUSTEP_BASE_LIBRARY
...
#endif

since this is what you almost certainly want!

Note: Apparently OGo uses the "GNUSTEP" define in some places to find out whether the GNUstep environment variables should be used for resource lookup. Nicola correctly pointed out that the NSSearchPathForDirectoriesInDomains() function should be used instead of querying. Since NSSearchPathForDirectoriesInDomains is not implemented in libFoundation, we cannot use it in OGo code without proper defines.
So, please be careful with the GNUSTEP define and with NSSearchPathForDirectoriesInDomains - we won't accept patches that do not work with libFoundation.

Whether import is allowed to be used or not is a discussion between Apple and GNU running for years now ;-)
In short: you need to use #import on Foundation headers if you want to be compatible with MacOSX since MacOSX header files are not protected against multiple inclusion.

So: in OGo, always use #import when importing things from Foundation and use #include if you import anything from OGo itself.

Note: #import is *not* deprecated anymore in gcc! It fully works but has a slight performance penalty in the recent gcc cpp.

As written in the mailinglist, we won't accept patches which will break libFoundation or Cocoa compatibility!
This doesn't mean that you are required to test all your patches on MacOSX, but rather that you should be aware of multiple library combos and take that into consideration.
For example if you have a section like:

#if LIB_FOUNDATION_LIBRARY
some code
#else
some other code
#endif

and if you need to fix "some other code" to work on GNUstep, please keep in mind that "some other code" might work perfectly on Cocoa. So if you can't check, whether your new code works on Cocoa, please add an additional case:

#if LIB_FOUNDATION_LIBRARY
some code
#elif GNUSTEP_BASE_LIBRARY
// TODO: check whether this code works on Cocoa
some gnustep-base code
#else
some other code
#endif

Placing the TODO marker will help to remove those ugly #ifdefs later on ...

In OGo we sometimes use the NSString method -indexOfString:, which is not available anymore in gnustep-base or Cocoa. It's unclear whether it was removed in those Foundations or whether it is a libFoundation extension.
Anyway, during porting we should replace -indexOfString: with -rangeOfString: which is supported on any Foundation.
Important: with -indexOfString: one checks for the NSNotFound to find out, whether the string is contained in the receiver. This is different with the -rangeOfString: method - which doesn't modify the range location to NSNotFound but rather sets the range length to zero.

Wrong: Even the pref string was not found, the location will be 0, not NSNotFound:

- index = [lowServer indexOfString:pref];
+ index = [lowServer rangeOfString:pref].location; // WRONG!
if (index != NSNotFound) {

Correct: If you use -rangeOfString:, you need to check the length, to find out whether something was actually found:

r = [lowServer rangeOfString:pref]
if (r.length > 0) {

Style: when searching using -rangeOfString: we should use the length property of the range for string operations instead of using statics, eg:

this:
r = [x rangeOfString:@"Action"];
trailer = [x substringFromIndex:(r.location + r.length)];
instead of:
trailer = [x substringFromIndex:(r.location + 6)];

When you need ceil() or floor(), include <math.h>, not js/jsmath.h, which is just for the SpiderMonkey JavaScript engine.

There was a long discussion about the patched and "old" OGo version of gnustep-make. Nicola (and others) is very much in favor of using the current version of gstep-make (for understandable reasons).

In short: we will not upgrade the gnustep-make package at this time for deployment - the GNUstep make environment is too "API-unstable" between minor releases to be used in production deployments.

Important: We do not think that gstep-make is unstable from a functional point of view at all - it's very stable in this respects. But past releases often contained "API" changes, like in the directory layout, which even sometimes require a recompilation and certainly require a repackaging and incompatibility for deployments.
That is certainly acceptable for an environment primarily used by software developers, like GNUstep, but not for a mission critical enduser application like OGo.

That being said, we do *not* think that this poses a big problem in practice since the makefiles of OGo itself should be compatible with the latest gstep-make versions and if not, can be certainly be adopted to work with both versions.