Writing portable code

GNUstep opens up some fairly interesting opportunities to target a number of platforms with the same source code, for example porting Mac OS X Cocoa applications to Linux, the BSDs, other Unices and (ultimately) Windows without significant re-engineering effort or degraded end-user functionality.

Some portability gotchas are listed below (please update when you run into a new one!):

Porting Applications

You can generally convert NIB bundles from NeXTSTEP and OPENSTEP to GNUstep using the nib2gmodel tool.

• nib2gmodel Something.nib Something.gmodel
• Open the gmodel file in Gorm on GNUstep and save it as gorm

Porting from GNUstep to Cocoa

tbd.

Porting from Cocoa to GNUstep

Porting from Cocoa to GNUstep has different aspects.

First there is the compatibility of the basic Foundation Kit and Application Kit. We support a lot of classes, but not all of them and the same is true for specific methods, Specifically newly introduced classes and methods may still be missing as GNUstep started out aiming at OpenStep compatibility.

Second you have all the additional frameworks and libraries programmers on Mac OS X take for granted, for some of them free replacements exists, for most they are still missing.

Mac OS X developers should try and avoid CoreFoundation as this will complicate your dependency situation on non-Mac hosts, even if that part of CoreFoundation has actually been ported.

GNUstep Base and the FoundationKit offer many parts of the CoreFoundation functionality in a natural Objective-C manner.

The porting itself

short overview:

• write a makefile
• convert your NIB files to gmodel
• provide an Info.plist.

detailed instructions:

1. you need to write a new GNUstep make file for the project (very easy, still there is currently no automatic way to do so)
2. you need to convert the NIB files to GNUstep format. At some point in time GORM will be able to read NIB files, but currently you need to use the gmodel intermediate format for this and for this the above mentioned tools are used.

Don'ts

Don't use anything we do not provide:

• don't use CoreFoundation
• don't use KeyChain
• don't use Carbon
• don't use Quartz
• don't use QuickTime

gcc mainline currently doesn't support ObjC++ although it is already in the works somewhat (expected for gcc 4.1). that means:

• don't use WebKit (currently)

gcc mainline also does not support altivec, this is an apple specific extentsion, that means:

• don't use altivec features or the vecLib.framework (a collection of functions for vector manipulation).

Stumbling Blocks

• Apple's Cocoa.h

it is there to enable pre-compiled headers and speed up compile time thusly. Anyway, it contains just two lines:

#import <Foundation/Foundation.h>
#import <AppKit/AppKit.h>

So you can easily work around this by providing your own or replace your include of <Cocoa/Cocoa.h> with just the above, which will also work on OS-X.

• When you need to distinguish between Cocoa and GNUstep, you may use the following

#ifdef GNUSTEP
    /* GNUstep code goes here ... */
#else
    /* OS-X Cocoa native code goes here ... */
#endif

Porting the .nib files

First get nib2gmodel, follow the included instructions to build and install it. Once that's done you're ready to begin:

• Run the nib2gmodel program on your nib like so:

  nib2gmodel mygui.nib mygui.gmodel

This should create the .gmodel as a plist. I recommend that you convert the gmodel to a "normal" plist instead of an XML plist. You can do that by doing this on OS X:

  pl < mygui.gmodel -output mygui.ser
  pl > mygui.gmodel -input mygui.ser
  rm mygui.ser

• Now you can either use the gmodel as it is, or you can convert it to a .gorm file.

Gmodel to .gorm conversion

NOTE: Conversion from gmodel to .gorm is experimental and will probably remain so for a while. It currently works in the majority of cases, but there are still improvements which need to be made.

Conversion to a .gorm file is relatively straightforward:

• Start Gorm.app.
• Choose Gorm->Document->Open and find the gmodel you wish to load.
• Gorm will prompt you to either define the superclass for classes it doesn't know about or to parse the headers.

After you've defined all of the unknown classes, Gorm should complete the conversion. Once this is done you should save the result to make sure you don't loose your work.

FIXME: add following:

• how to convert xCode project to GNUstep project (creating a GNUstep Makefile or ProjectCenter)

Notes

Do not rely on tools available in development environment

All the world is not Linux or FreeBSD or Windows. System constants may be different on different platforms. Paths to command-line tools, the parameters they accept and locations of temporary directories may be different to what you are used to on your platform.

• GNUstep Base and the FoundationKit offer some of this functionality "for free".
• Try not to hard code paths and so on into your code, use macros (not recommended), or even better an abstraction mechanism.
• Avoid hard-coding system constants, or platform-specific ones where Posix or commonly-accepted ones exist (and we're not talking about glibc here :-)