Re: porting to GNUstep from OSX

[Marcus Müller]

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
> this...

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
> PyObjC.

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.


Cheers,

  Marcus

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