[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: porting to GNUstep from OSX

From: Marcus Müller
Subject: Re: porting to GNUstep from OSX
Date: Thu, 10 Jul 2003 02:15:46 +0200

On Thursday, July 10, 2003, at 12:20 AM, David Bishop wrote:

On Wednesday 09 July 2003 03:53 pm, Marcus Müller wrote:
Hi David,
I recently ported OCUnit to GNUstep. Marco forwarded me your email
regarding incompatibility with gcc 3.3. So far, I have only be able to
test with Apple's gcc 3.3 on Panther - no problems at all. The missing
header forces a warning, but that's not fatal.

The build goes fine, the link fails (for me). I'm thinking the OSX runtime
defines those while GNUstep doesn't.

That's probably true. I'm not using gcc 3.3 on FreeBSD, yet, so I cannot reproduce these problems currently.

Regarding your port, could I get ahold of it somehow? I'm more than willing
to test stuff out, and I have access to both Jaguar and GNUstep.  I'm
ecstatic that someone else did it already, I have no pride bound up in

Marco released it recently, it's available from Sen:te's website at http://www.sente.ch/software/ocunit/.

And finally, what exactly did you have to change to make OCunit work with GNUstep? I have a feeling that I will be doing very similar things with

Class loading differs between the GNU and NeXT runtime. The problem is that the semantics of +(void)load are completely undocumented, so there's noone to blame for that. ;-) With OCUnit this bit is somewhat problematic, because OCUnit heavily relies on certain classes being available at a specific time so that they can be collected in the runtime. OCUnit enforces this by calling +(void)initialize from +(void)load in a specific class - this is highly problematic and probably not portable. Because of this and some other reasons I had to extend OCUnit to provide a better, more portable entry point. There's now a function that you can call from the main() function of your test tool. I don't think that anything of these things is relevant for the porting of PyObjC at all - there's probably much more runtime fiddling involved there.

I don't know how the header problem could be solved elegantly besides
using autoconf, but that wouldn't be acceptable on OSX anyways - it
just doesn't fit into the picture using PBX (or Xcode).

Not knowing a ton* about the build process of PBX/Xcode, does it allow for tests at all? At least in PyObjC you run setup.py, which has some (very,

Yes, Sen:te did this for PBX. It doesn't work with Xcode out of the box, though.

very, basic) tests to see what version of OSX you are using, and if you are on GNUstep or not. Pretty much everything that needs to be done can be based off of that (at least so far). Maybe just some #ifndef's, combined with -D's
in the GNUMakefile would be enough? (I.e., #ifndef GNUSTEP #include
<objc/runtime.h> #endif)

PBX/Xcode are not really aware of autoconf and thus autoconf doesn't fit into PBX/Xcode well. But that point is pretty obvious - Apple has its own cross-platform strategy and solutions. In my opinion it wouldn't be wise to force autoconf into the PBX/Xcode build process, but rather provide two different approaches - one for GNUstep, the other for Apple. Of course setup.py is similar to autoconf, so that applies to setup.py as well.

And last and definetly least, did he forward my message about making all the headers in ocunit #include-safe? How useful is that exactly? I didn't know if that was something that only the gcc-guys cared about, or if GNUstep'ers
were also anti-import...  (If he didn't forward that message, at
http://bishop.dhs.org/~david/senheaders.tgz is a copy of all the ocunit
headers, fixed to work without -Wno-imports flag)

No, I didn't receive this mail. In our major projects (EDC/EDM/XMLRPC) I made sure that all headers are safeguarded and I replaced all occurences of #import with #include with the notable exception of <Foundation/Foundation.h> and <AppKit/AppKit.h>. I sincerely hope that Apple will safeguard these headers soon so we can change them as well.



Marcus Mueller  .  .  .  crack-admin/coder ;-)
Mulle kybernetiK  .  http://www.mulle-kybernetik.com
Current projects: finger address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]