gstep-base Re: [OGo-Developer] OGo Invoice Application

[Sebastian Reitenbach]

Hi,

> Just to reiterate what needs to be done for a gstep-base port:
> 
> a) make OGo (fully) working with it. This might seem like little
>     work but locating and eliminating gstep-base incompats are a
>     huge time killer. Note that I say gstep-base incompats because
>     OGo does work quite well on Cocoa. I suspect that this is
>     because Cocoa cares about API compat, even if its legacy
>     according to Foundation docs ...
sogo is using with gnustep-base, so sope is known to work with it.
But I know, there are still subtle compatibility bugs regarding ogo, e.g. 
memory management...

> 
> b) make OGo/SOPE on gstep  install and work in a *proper* FHS
>     hierarchy, preferably the same like we have now. This is
>     probably a lot of work, it means bumping all makefiles to
>     gstep-make-2.x, either port the old fhs.make to that or use
>     the new gstep-make-2.x FHS support (which might be quite
>     different to what we want), and fix the code to honour new
>     layouts.
I've created sope gnumakefiles to be compatible for gnustep-make 2.0.
I just removed the fhs.make stuff, using the gnustep-make builtin stuff.
But I have no real idea, what exactly you mean with *proper* FHS layout.
Is there a document that states, what would be a acceptable layout or not? 
I've no idea how my sope makefiles would work together with cocoa on a Mac.
In my eyes, this point b is the easiest to solve, and I'd go update my sope 
gnumakefiles, and create some for ogo, but it would really really help, if 
there is a document that states, how a good layout would look like. Reading 
the existing makefiles to figure out, is a lot of hard work.
OK, I hope to get some new gnumakefiles for ogo done in the next days, and 
will post them here or on the ogo-gnustep-port@ list.


> 
> c) make gstep-make/base API stable. Doing that once is easy because
>     we could just make a vendor branch and use it. But the vendor
>     branch would need maintenance as well, and a fork in general
>     s***s. This is an inherent gstep issue and I would be
>     massively surprised if it would go away ;-/
again, sogo is based on gnustep-base, so in my eyes, it cannot be such a big 
deal. Well I have no idea, how much time is spent to keep sogo compatible 
and working with gnustep-base. As I am subscribed to the CVS changes of 
gnustep-base, I see the changes that happen day by day. It's not that 
overwhelming ;)

> 
> Personally I would love to see gstep-base replace libFoundation for  
> the ObjC code, but unless the issues above get resolved there is  
me too.

> little hope. And since all of points are quite a bit of work, my  
> (current) assumption is that they will probably never happen.
you know that I am from time to time try to compile ogo against gnustep-base 
and get it running. I hope to get the problems fixed in 2008.

> 
> Personally I would prefer to focus on getting JOPE compiled and  
> working with the GCC Java compiler (GCJ).
Personally I have a hate against Java (I know it's a bit stupid, but it is 
just as it it), and I doubt that will change in the near future ;) As I do 
all that OGo hacking in my spare time, for me its all about fun. I just 
don't have fun with Java.

cheers
Sebastian
> 
> Helge
> 
> PS: obviously Java has BigDecimal ;-)
>