Re: import vs include Re: Porting autogsdoc to OSX

[Marcus Müller]

On Dienstag, Februar 26, 2002, at 11:43  Uhr, Helge Hess wrote:

> To the specific problem: gstep-base may or may not use #import 
> internally, but gs-autodoc should use #import because otherwise it's 
> not OpenStep conform and therefore not portable. OpenStep requires 
> #import and doesn't require safe-guarded headers.

Well, I agree. Until now I didn't see the point, but yes, it's a 
userland tool (although shipped with base) and requirements (like 
#import vs. #include) could be seen different here. But anyway, I didn't 
intend to overstress the debate here. Personally I'd favor Helge's 
proposal.

> I'm also amazed that MIME and XML functionality is put into gstep-base. 
> Why does a *Foundation* library require XML and MIME functionality ??? 
> Hm. Gstep-base is IMHO radically violating the one major feature of 
> OpenStep, portability between Foundations. That way you will never 
> reach MacOSX developers ...

Well, I think everybody agreed that the current situation isn't the 
best. Also, the last statement isn't true: I am a Mac OS X developer 
and - as opposed to my everyday job - I am toying around with GNUstep in 
my spare time. I like the whole concept of GNUstep, but sure - due to 
lack of developers - these issues didn't need to be addressed until now 
I guess.

Regarding the XML and MIME functionality: I spent most part of the 
evening reviewing all parts in base which have #ifndef NO_GNUSTEP 
assigned (as these are the parts I do have to port over to OS X) and 
since found out that most of them are NON TRIVIAL to port. However, the 
good news here is, that most of this code seems to be used internally 
only (by gstep-base), thus it will rarely be called by userland programs.

I began porting the critical parts to a new library which could be 
transformed into a bundle on GNUstep. Doing so after about 2 hours I 
found out that this task has to be repeated by a maintainer because the 
parts that I separated have to be removed from the [.hm] files in base 
(obviously) and thus stopped it. How could we proceed efficiently at 
that point?

For me it would be feasible to rip all code which consists of 
definitions, functions and categories and put it into a new framework. 
Dirk Theisen had done exactly the same some time ago and contributed his 
code, so it's pretty much complete by now. However it would be more than 
perfect to not duplicate the effort but instead put the stuff into 
gnustep-base as soon as that can be accepted by the maintainers. For 
that to be done of course there has to be a review in order to agree on 
naming (categories, filenames). I did preserve the names from base 
(where there had been category names) in order to not change things too 
much.


Proposals are welcome! ;-)

<Marcus


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