[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem porting sogo to use gnustep-make 2

From: Helge Hess
Subject: Re: problem porting sogo to use gnustep-make 2
Date: Fri, 11 Jan 2008 00:06:46 +0100

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

- this one does some kind of automatic lookup

- 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
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.

Helge Hess

reply via email to

[Prev in Thread] Current Thread [Next in Thread]