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.