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.
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
Marcus Müller.
People currently involved:
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.
Fixed a URL processing issue due to a bug in Cocoa Foundation NSURL. Mod_ngobjweb builds and runs out of the box!
Update: 2004-10-10At 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.
Update: 2004-06-10
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).
Update: 2004-02-23
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).
Update: 2004-02-13
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
on Panther.
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.
Update: 2004-01-06The 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 sections).
Update: 2004-01-04Helge 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.
Update: 2003-11-27
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
library.
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
on FoundationExt.
See the status overview below.
| Component | Status | Notes |
| ThirdParty | ||
| libxml2 | ported | comes with PBX to build framework |
| libical | ported |
comes with PBX to build framework included in 10.3 |
| libFoundation | not ported |
- might work with Fink, GNU gcc and dlcompat - not relevant for the "regular" port, as we want to use Cocoa Foundation |
| gstep-make | not ported | use the gstep-make from the GNUstep website on MacOSX. This one is more current and already ported to OSX. |
| gnustep-db | Note: not all functionality is ported! | |
| SOPE | ||
| skyrix-xml |
|
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 in Publisher) |
| skyrix-core |
|
- 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) |
|
| Logic | ||
|
|
Note: not all functionality is ported! | |
| DocumentAPI | ||
|
|
- Note: not all functionality is ported! - The Xcode project is missing the datasource bundles. - seems to work fine with gstep-make. |
|
| WebUI | ||
| OGoFoundation | seems to work fine | |
| OGoForms | not tested | |
| OpenGroupware.org | seems to work fine | |
| Common | seems to work fine | |
| Contact | seems to work fine | |
| Mailer | not tested | |
| Scheduler | seems to work fine | |
| Project | - issues with fault resolution in OGoNote if you want to edit a note of an appointment you entered using the contacts appointments tab | |
| Tasks | has issues with LSWTableView and sorting (exception) | |
| ZideStore | ||
| Some ZideStore products are hurt because they define categories on classes defined in other products (bundles). This doesn't work with the MacOSX linker. | ||
| EvoConnect | does not compile on MacOSX | |
| XML-RPC Daemon | ||
| Publisher | ||
| - Note: has path processing related issues! | ||
| PDA (Palm Sync) | ||
| port not started | ||
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.
IssuesHelge needs to summarize more issues he knows about an OGo Cocoa port ...
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.
A:
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.
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.