Porting to MacOSX can be done in several different ways. MacOSX is special
in that it comes with an own Objective-C runtime environment, including an
own Objective-C runtime and an own Objective-C Foundation library.
So, depending on the approach, a MacOSX port can be either a system level
port to the Darwin BSD system or it can be a port to the Cocoa Objective-C
environment. The latter is certainly the preferred goal providing much
better integration with MacOSX.
Also, the build system is quite an issue. OGo uses an own branch of
the GNUstep makefile package
which will not support building on MacOSX. However, a current CVS version
from the GNUstep CVS repository will do.
Organizer / Contributors
On MacOSX the build environment of choice is Xcode, however. This
implies that for proper MacOSX support we will have to create Xcode
projects for all OGo subprojects accordingly and - much more important -
keep them in sync with the main build system while things change.
Because Xcode project files are not (easily) human readable
this is a troublesome step. While Xcode support is somewhat desirable,
it's not strictly necessary for getting OGo to run on MacOSX, however.
There is no specific organizer for MacOSX ports yet. For now, just contact
People which work/worked on the port:
If you're mainly developing on MacOSX, you might want to take a look
at the SOPE:X project in the Contrib section of OGo. In short, SOPE:X
is a framework and Xcode template set to improve the development
experience on MacOSX. It includes an innovative new way of running SOPE applications as regular MacOSX desktop applications
(by making use of the new WebKit framework). Further information
is included in its README.
The web interface compiles and works just fine on MacOSX. Some ZideStore
plugins are disabled due to OSX linking issues.
Compilation on OSX 10.4 produces a lot of warning which you can ignore, gcc 4.0 just got even more strict on some previously legal constructs.
Fixed a URL processing issue due to a bug in Cocoa Foundation NSURL.
Mod_ngobjweb builds and runs out of the box!
At least one umlaut issue in SOPE on MacOSX was fixed. SOPE 4.3 and OGo 1.0a
compile just fine on MacOSX. The Xcode projects of SOPE 4.3 are cleaned up
and ready for use.
Various tweaks and fixes for compilation with gstep-make. Prebinding for SOPE
is now also supported when compiling with gstep-make, all the makefiles are
fixed with regards to missing/changed library search pathes.
Further, ZideStore now builds and runs on MacOSX using gstep-make. We will
need some sourcecode reorganisation to support Xcode builds.
A lot of work by Stephane Corthesy to improve SOPE compatibility with WebObjects 4.5.
The Xcode 1.2 update apparently introduced changes in the dependency tracking
of gcc which broke compilation of OGo using gstep-make. This was fixed for
most packages in CVS head by adding explicit references. Yet there seems to
be a general problem with gcc locating _available_ libraries (this was also
confirmed for recent gcc on regular BSD).
So far the basic issues of the port still exist which are:
NSNull handling and broken output for non-ASCII characters.
A change to use the Foundation key/value coding instead of an own one
unfortunately seems to introduce quite some issues in conjunction with
NSNull. For example OGo KVC returns 'nil' when -valueForKey: is used on
an NSNull value contained in an NSDictionary. Cocoa KVC returns the actual
NSNull object, so client side code needs to deal with that.
In general NGExtensions/FdExt/NSNull+misc.m already contains a lot of
"catcher" methods which work around NSNull values in unexpected places -
this is a hack and needs to be fixed.
Several "WO" fixes were applied on SOPE, we now have proper support for
.woo files and support for WebObjects Builder templates. In addition ZNeK
fixed some minor issues in NGObjWeb, enhanced SOPE:X a lot and did apply a
more performant workaround for the "mutable dictionary" issue (using some
private CoreFoundation API which might go away in 10.4).
Several fixes (and hacks) were applied on the OGo source tree to support OGo
in gstep-make on MacOSX. It now works pretty well and was actually used to demonstrate OGo on an iBook/OSX 10.3 at FOSDEM!
Nevertheless some "fixes" are rather hacks: a) somehow Cocoa tries to invoke
various methods on NSNull objects, something is wrong here, b) on Cocoa we
cannot find out whether a dictionary is mutable - affects NGObjWeb and is hacked around using NS_DURING.
Marcus Mueller committed the source of SOPE:X in the Contrib section of
the CVS repository. SOPE:X is a framework and Xcode template set to improve the development experience on MacOSX. It includes an innovative new way of running SOPE applications as regular MacOSX desktop applications (by making
use of the new WebKit framework).
Friday, the 13th. Hm. OpenGroupware.org now builds and runs! on Panther using gstep-make. Of course it still has a lot of bugs and issues (for example problems with umlauts and the task application isn't working yet), but otherwise it looks just fine.
Next step: build a package.
WebUI builds using gstep-make! All the makefiles are corrected and lots of
tweaks were made. In addition ZNeK added proper prebindings to the Xcode
frameworks of SOPE:X.
Now we need to check whether it actually runs ... at least Publisher has
problems with NSPathUtilities which actually require valid local pathes
ZNeK has cleaned up the Xcode projects of skyrix-xml, skyrix-core and
skyrix-sope. In addition he has added proper umbrella frameworks so that
linking against a framework set is much easier.
The gnustep-db, Logic and DocumentAPI now all compile with gstep-make on
MacOSX. Notably various things are not yet ported, so functionality should
be buggy in various sections (compilation issues FIXME warnings on those
Helge did some work on the gnustep-db parts. Relevant parts of FoundationExt
are now included as a subproject of gnustep-db and various other tweaks are
removed. It probably doesn't work yet, but got a major step forward.
One of my major complaints with MacOSX development is that neither Xcode nor
IB use an abstract XML (or plist) storage representation but rather use
serialized object graphs (yes, like some MS data formats they try to masquerade as XML, but I'm not going into that trap ;-).
This results in new fileformats for almost any release and it makes working in a distributed team on the same codebase *really* hard.
Summary: Helge started to create Xcode projects in addition to the PBX ones.
The project is still mostly stuck at the port of ThirdParty/gnustep-db.
Helge did some work on compiling OGo on MacOSX using the gstep-make package
(the current one from the GNUstep website) in the apple-apple-nil combo (that
is with Apple runtime and Apple Foundation).
So far this seems to work pretty well up to SOPE (well, compilation on G4/OSX
is slow as hell, so if anyone has a spare dual-G5 ;-). It's currently breaking
at gnustep-db, which requires proper adjustments for the missing FoundationExt
Note: this process currently produces shared libraries, not frameworks.
Nicola has done some work on a new make project which produces frameworks on
OSX and shared libraries on regular Unix systems, we'll check that out later.
Marcus and Helge did some work on the PBX files of SOPE - skyrix-xml,
skyrix-core and skyrix-sope should now operate without the dependency
See the status overview below.
comes with PBX to build framework
comes with PBX to build framework
included in 10.3
- might work with Fink, GNU gcc and dlcompat
- not relevant for the "regular" port, as we want
to use Cocoa Foundation
use the gstep-make from the GNUstep website on
MacOSX. This one is more current and already ported
Note: not all functionality is ported!
no issues, clean compilation, no warnings
remember that Library/SaxDrivers should contain a driver ...
Note: libxmlSaxDriver is not build per default - the CFXML driver
is used instead (eg you need libxml for parsing HTML entities
- does the NGBundleManager properly work? (shows warnings)
- prints a warning that OSX does not support locked TTY, probably
a non-issue (maybe remove all that code, being unused?)
- a lot of warnings on -initWithSource: prototypes
- quite some warnings because of changed API in OpenLDAP v2 (need to
fix on GNU/Linux as well)
- still uses the runloop "hack" => ZNeK is working on a rewrite of
NSRunLoop+FileObjects which uses the CoreFoundation API
- some smaller warnings in tools
- Note: requires a js.framework
- Issue: UnixSignalHandler?
- Note: don't forget to setup links in Library/SoProducts for the
core SOPE products if you want to use the "sope" tool,
otherwise you get an infinite recursion (due to OFSHtpasswd
no being found)
|Note: not all functionality is ported!
partly compiles (Xcode)
- Note: not all functionality is ported!
- The Xcode project is missing the datasource bundles.
- seems to work fine with gstep-make.
||seems to work fine
||seems to work fine
||seems to work fine
||seems to work fine
||seems to work fine
- issues with fault resolution in OGoNote if you want to edit a note
of an appointment you entered using the contacts appointments tab
||has issues with LSWTableView and sorting (exception)
Some ZideStore products are hurt because they define categories on
classes defined in other products (bundles). This doesn't work with
the MacOSX linker.
does not compile on MacOSX
- Note: has path processing related issues!
|PDA (Palm Sync)
||port not started
Porting to Cocoa
First, most of the core stuff should at least compile on Jaguar without
too much hassles and even the higher level stuff should compile without
big problems. And some stuff already comes with ready-made PBX files.
Helge needs to summarize more issues he knows about an OGo Cocoa port ...
libFoundation NSRunLoop additions for watching file descriptors
Also take a look at GNUstep issues
How to find out whether an NSDictionary object is mutable on Cocoa Foundation? NSCFDictionary is used for both?!
NSPathUtilities on Cocoa work for the local filesystem only! So we
probably need an own variant
Some charset issues with property lists (eg Defaults.plist)
Q: I started trying to build, but don't seem to be able to find the FoundationExt that's required (grepping the source tree). I first suspected
the extensions that come with libFoundation, but those appear to be different. Some googling revealed that they might be a part of gnustep.
The PBX are somewhat "old" (out of sync) - until some months ago you were required to use the so called FoundationExt library which contains all the extensions coming with libFoundation for other Foundation libraries (like subclasses of NSException or RETAIN/RELEASE macros or UnixSignalHandler etc).
Actually I think I moved most/all of the required things into NGExtensions (skyrix-core) and actually the code should be independend of FoundationExt now. "should" like in "did not test".
So if the PBX contains link reference to the FoundationExt.framework just remove it and with some luck it will just compile. On the other side you may need to add some more (new) source files in NGExtensions to the PBX.
In short: OGo should work completely without FoundationExt. If stuff is missing, move to NGExtensions or rewrite the code to work without.
It seems that people agreed in the mailinglist that we should use
gnustep-make for compilation on MacOSX. This has the advantages that
we only need to maintain a single build environment, and more important,
that we can actually work in a multiuser environment on the makefiles
(which is basically impossible with PBX due to it's binary nature).
Obviously we should use the latest gstep-make version from the GNUstep
project on MacOSX, since the OGo gstep-make certainly doesn't include
all the MacOSX fixes Nicola has done in the meantime.
One issue with that approach is that we definitely want to use frameworks
on MacOSX and definitely do not want to use frameworks on ELF platforms.
It's still open whether we can change gstep-make in a useful way, so that
library.make generates frameworks on MacOSX.
Porting using Fink
TheSin [hu? ;-)], has started
trying to port OGo using dlcompat for Fink. Check the mailing list archives
of the macosx and developer mailing lists if you are interested in that.
Search Mailinglists on FreeBSD