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

[Sebastian Reitenbach]

developer@opengroupware.org wrote: 
> On 02.01.2008, at 12:38, Sebastian Reitenbach wrote:
> >> OK, but how would it continue then? SOPE must know where to search,
> >> und unlike the current solution using "GNUSTEP_WEB_APPS" at the
> >> compile time (eg passing it in using -D...) would make the binary  
> >> non-
> >> relocatable! (because GNUSTEP_WEB_APPS is indeed a compile-time  
> >> path).
> >>
> > I don't understand why it then is less relocatable than it is right  
> > now.
> > I did not meant to define an absolute path, just only a relative  
> > subdir.
> 
> If you do that, it would be OK. But GNUSTEP_WEB_APPS is, AFAIK, an  
> absolute path? You would need something like GNUSTEP_WEB_APPS_RELDIR.
In case GNUSTEP_WEB_APPS is an absolute path, then it shouldn't be too hard 
to strip GNUSTEP_ROOT out to make it a relative path.

> 
> >> So what is required is a way to query GNUstep for the value of
> >> "GNUSTEP_WEB_APPS".
> >>
> >> [BTW: GNUSTEP_WEB_APPS is not the best place for SOPE stuff. This is
> >> for the gnustep-web binaries]
> > Anything better in mind? I'm open for everything, and I think Nicola  
> > would
> > add also new Variables/path locations if they are reasonable.
> 
> Maybe SOPEApplications? Don't know. We could just install them in  
> WOApps like before.
> Or we always build them in tools and place them in Tools.
> 
> >>> When the whole process then gets well documented in a INSTALL file  
> >>> in the
> > sources, then I think, this will stop the "where do I find rpm for  
> > Distri
> > XXX", or other similar question that show up there from time to time  
> > on the
> > users ml.
> 
> Well, that belongs into discuss. Adam already said that he would  
> prefer to keep packages. And it definitely is an issue for the  
> majority of the OGo users not to have packages.
ok, but for someone who maintains packages already for a distri, it might 
not be too hard to change/upgrade these. As said, i do not know much enough 
about all the different kinds of packages.


> 
> > At least, for OpenBSD I'd like to create ports files. I do all gnustep
> > upgrade stuff, because the gnustep-make and gnustep-base packages  
> > are well
> > maintained there. I'd like to start creating ports on them?
> 
> IMHO its a bad idea to base work on 'official' packages. The problem  
> is that GNUstep broke the ABI quite often in the past. This is quite  
> an issue because you get at least one, more likely 2 releases per  
> year. Now if you have 5 different distris, they are unlikely to always  
> have the same ABI.
> 
> This issue doesn't matter that much for GS developers because they  
> always work in trunk. But for thirdparty guys its a mess.
> 
> Actually you experience the issue first-place! :-) You can't use OGo  
> on OpenBSD because gstep-make API incompatible. While Debian is  
> (AFAIK) still on gstep-make 1.13 (which is why SOGo has no issues).
> 
> 
> >> BTW: we would also need to create a gnustep-make/gnustep-base vendor
> >> branch to stabilize it for OGo usage.
> > also what about sogo?
> 
> Yes, thats also an issue.
> 
> > At least there  the packaging constraint is not a problem, as just  
> > there are none.
> 
> I think Inverse now provides packages. AFAIK they use the system  
> GNUstep (1.13).
well, debian is known to be soooo slow in updating packages ;)
ok, then the sope would include the gnustep-make 2.0 package, and install 
this together as sope.

> 
> > But the sogo makefiles have to be updated too.
> 
> Yes.
> 
> > Wolfgang, do you are here on the list too?
> > I could update these for sogo too, as I would like to see sogo to  
> > work on
> > OpenBSD too, and then create ports ;)
> 
> Si! Probably best to just do it and then send a patch to Wolfgang. But  
> its better to start a new thread on sogo@ogo.
ah, ok, I'll do.

Sebastian
> 
> Greets,
>    Helge
> -- 
> Helge Hess
> http://www.helgehess.eu/
> -- 
> OpenGroupware.org Developer
> developer@opengroupware.org
> http://mail.opengroupware.org/mailman/listinfo/developer
>