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

[Sebastian Reitenbach]

developer@opengroupware.org wrote: 
> On 27.12.2007, at 08:03, Sebastian Reitenbach wrote:
> > sogo is using with gnustep-base, so sope is known to work with it.
> 
> So what, SOGo was built something like 8 years after OGo and is a  
> significantly smaller codebase, and is currently developed on top of  
> gstep-base.
> 
> > But I know, there are still subtle compatibility bugs regarding ogo,  
> > e.g.
> > memory management...
> 
> Exactly. As I mentioned, Cocoa works quite fine, so its not really OGo  
> specific.
> 
> >>
> > But I have no real idea, what exactly you mean with *proper* FHS  
> > layout.
> 
> Well, what is the FHS layout you accomplished? Do the server binaries  
> properly live in sbin. Are binaries properly versioned and can be  
> installed in multiple versions?
yes, they are in sbin and have the version numbers, 
e.g. /usr/local/sbin/sope-4.7.

> 
> > Is there a document that states, what would be a acceptable layout  
> > or not?
> 
> The wished for layout is the one we currently have (more or less what  
> is required by FHS/Debian?!).
afaik, there are gnustep-make packages for debian. so there is a filesystem 
layout specified for debian, and other distris/OS have their own. I think 
however these gnustep-make packages are installed, they have the correct 
filesystem layout for the system already configured/setup. 

> 
> > I've no idea how my sope makefiles would work together with cocoa on  
> > a Mac.
> 
> That shouldn't be an issue.
ah, ok good.
> 
> > In my eyes, this point b is the easiest to solve, and I'd go update  
> > my sope
> > gnumakefiles, and create some for ogo
> 
> Yes, it would be very nice if we could move SOPE and OGo to gstep-make  
> 2.0.
ok, then this just raised in priority, I'll see that I can provide some 
patches to the gnumakefiles for sope and ogo in the next days.
> 
> > but it would really really help, if  there is a document that  
> > states, how a good layout would look like.
> 
> That would be the FHS standard. Its probably easiest to look at the  
> current layout ... But actually its rather simple:
> 
>    ROOT/
>      sbin/
>        ogo-webui-x.y
>        ogo-zidestore-x.y
>        ...
>      bin/
>        ogo-account-add-x.y
>        ...
>      lib/
>        libOGoABC.x.y.z
>        sope-x.y/
>        zidestore-x.y/
>        opengroupware-x.y/
>          commands/
>            ...
>          datasources/
>            ...
>          webui/
>            PersonsUI.lso
>            ...
>      share/
>        sope-x.y/
>        zidestore-x.y/
>        opengroupware-x.y/
>          templates/
>            ...
OK, I see, and I think that should work very well with gnustep-make 2.0.X.

> 
> 
> >> 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.
> 
> I fail to see how your eyes work then, its rather obvious :-)
> 
> 
> > 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 ;)
> 
> The issue is that certain important things are quite unstable, eg KVC.  
> Subtle changes are done and few people really care about backwards  
> compat.
> Even non-subtle, large changes are done w/o upgrade pathes, eg just  
> consider how much work the gstep-make 2.0 brought to us!
ok, with gstep-make you are right, its incompatible. But in general I'd say, 
the gnustep-make 2. package makes a lot of thing easier in the makefiles.
Regarding the other things, I cannot say much about it as I am not a 
seasoned objective-c programmer, just lacking that much experience over the 
time.

> 
> 
> >> 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
> 
> Yes, it really is ;-)
and another point we agree...

greetings
Sebastian