Re: problem porting sogo to use gnustep-make 2

[Helge Hess]

On 10.01.2008, at 22:33, Nicola Pero wrote:
> Well, it really depends on how sogo is installing resources/files at  
> install-time and then finding them at run-time. :-)

There are basically two mechanisms:
a) NGBundleManager
b) NGResourceLocator

http://svn.opengroupware.org/SOPE/trunk/sope-core/NGExtensions/NGBundleManager.m
- this one does some kind of automatic lookup

http://svn.opengroupware.org/SOPE/trunk/sope-core/NGExtensions/NGResourceLocator.m
- this is for locating versioned resources

Those basically support two install variants, FHS and GNUstep with  
environment variables. Both variants get their own, relative lookup  
pathes.
Though IMHO the latter is superflous for server applications (it can  
be useful in multiserver installs, but then jails work just fine too).

The FHS layout is 'hardcoded', well, not really hardcoded, just  
conforming to FHS as the name implies ;-) It more or less splits  
bundles into a structure like
  lib/somedir-major.minor/[subdir]/shared object
  share/somedir-major.minor/[subdir]/resources
etc.
I was required to write NGResourceLocator because Foundation has no  
versioning API *and* I also want the code to work (as FHS) on MacOS  
(hence, GNUstep additions do not really help).

> If it has its own internal 'sogo-specific' mechanism, then well you  
> need to debug that mechanism ;-) - it might not have much to do with  
> gnustep.

Si. IMHO the first step is to find a GNUstep make config which  
represents exactly the same layout which was produced by my very  
hackish fhs.make hacks :-) Then all should work out of the box.

> If it's using the "standard" GNUstep resource location system (which  
> I'd  recommend), then you need to make sure that everything goes  
> through the standard GNUstep APIs, with no exceptions:

Unfortunately the API is insufficient. It might be extended, but then  
it won't work on MacOS.

> 1. at install time (in GNUmakefiles), specify all installation  
> locations using the gnustep-make v2 variables and terminology (eg,  
> GNUSTEP_LIBRARIES, GNUSTEP_TOOLS, etc. PS: Note that we also have  
> GNUSTEP_WEB_APPS that was introduced precisely for OGO/GNUstepWeb).

I find it confusing if GNUstepWeb and SOPE apps are installed in a  
single place, but anyways ;-)
And BTW: OGo/SOGo are both 'bundle driven', ie the application is just  
a small tool which loads bundles containing the real 'applications'.
(somewhat like a servlet container, urks ;-)

> 2. at run time, use the standard OpenStep/gnustep-base API  
> (NSPathUtilities and such) for locating resources; each gnustep-make  
> variable has a corresponding variable in that API to find the  
> resources.  gnustep-base will automatically map that to the local  
> filesystem and find it.

Well, I guess the biggest issue is that there is no API which supports  
proper versioning.

I guess one could rewrite NGResourceLocator to consider GNUstep.conf  
(I suppose this is required to retrieve the layout at runtime?) Though  
I won't do it, sorry ;-)
Currently the GNUstep part in NGResourceLocator checks for the  
GNUSTEP_XYZ *environment* variables. If they are set, it uses them,  
otherwise it falls back to FHS.

Greets,
  Helge
--
Helge Hess
http://www.helgehess.eu/