some might recall that on FOSDEM I announced to (try to) port autogsdoc to Mac OS X in order to replace MiscKit's AutoDoc for generating the documentation to the Mulle XMLRPC Framework [http://www.mulle-kybernetik.com/software/XMLRPC] as soon as Wocoa has taken place. Well, Wocoa is over now and last night I went through the hassles of porting autogsdoc to Mac OS X.
There are several things besides the one's mentioned at FOSDEM that struck me when porting the whole thing, but let's begin with the key observation: There are some extensions within GNUstep base that ideally wouldn't be in base but rather in something I named "GSExtensions". Some of the things that fall into this category are categories at i.e. NSString like -(BOOL)boolValue and such. While some (including this example) are fairly trivial to port, other's (like +(id)[NSBundle pathForGNUstepResource: ofType: inDirectory:]) do not have an equivalent in OS X's Foundation; it would also prove to be hard to invent it in Foundation using the same semantics as that would mean one would have to touch the OS X's Foundation framework's resources and copy i.e. DTDs and the like in there - which is something one wouldn't really like to do; unlike GNUstep which is an addon to other systems OS X is totally different in that respect and I barely touch any of the System resources at all. IMO the best idea to deal with this class of problems is to adapt a behavior specific to GSExtensions.framework on a platform like OS X. This means one could implement
(inside GSExtensions.framework on OS X)
[[NSBundle bundleForClass:[SomeClassWithinGSExtensions.framework class] pathForResource:ofType:]
and copy all resources specific to GNUstep into this framework's resources.
Another issue is the invention of new "concepts" inside GNUstep base. These are not just extensions, but something more complex (GSXML, GSMime). Building autogsdoc (and friends) requires these to be inside GNUstep base, but unfortunately OS X's Foundation doesn't know anything about these (sure). Ideally these would be moved into "GSExtensions" as well. I think Adam & Richard both agreed on this issue and the idea of having this defined as a bundle within GNUstep base was proposed by Richard if I remember correctly.
The last thing, which is somewhat odd, is that every #imports in GNUstep* are written as #includes. I think that this was done merely because nobody wants an #import statement (which is compiler specific) when the same can be achieved with an #include and additional checks in the included file preventing duplicate includes, right? While this might be feasible from a theoretical standpoint (personally, I don't know whether this is the case) it's pretty contra-productive in real life. OS X's headers don't have such constructs and hence don't prevent duplicate includes - which caused the compiles to fail several times.
A solution I've come across so far is to have a directory with stub headers for all of Foundation's headers, which basically "wrap" the #import statements and have that directory prepended to the header search tree. Are there any good reasons why GNUstep really needs #include statements and possibly cannot switch to #import?
For the time being I actually managed to compile autogsdoc but I still have to port all extensions in question to GSExtensions.framework. Also, some .h and .m files had to be touched, because there's now that extra library/framework and the dependencies have to be resolved differently then.
Does my argument make sense to all of you GNUsteppers? I'm aware of the fact that for the benefit of being able to use some of the outstanding GNUstep achievements on OS X this is possibly wasting scarce development resources which might be better put to use elsewhere within GNUstep. On the other hand it could possibly enable more OS X solutions being easily portable to GNUstep by providing an interface to the kind of macros (RETAIN(), RELEASE(), ...) that are not available on that platform but vitable for GNUstep.
Cheers,
Marcus
--
Marcus Mueller . . . crack-admin/coder ;-)
Mulle kybernetiK . http://www.mulle-kybernetik.com
Current projects: finger znek@mulle-kybernetik.com