[Top][All Lists]

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

Re: GNUstep.sh / env sanity patches

From: Richard Frith-Macdonald
Subject: Re: GNUstep.sh / env sanity patches
Date: Thu, 19 Aug 2004 10:07:21 +0100

On 19 Aug 2004, at 09:44, John Davidorff Pell wrote:

On 18 Aug 2004, at 01:19, Richard Frith-Macdonald wrote:
True, but you need a relocatable install. In this case it would make sense for all the GNUstep stuff to use relative paths from where they are being run from, so when you run .../Tools/mytool it will know that ../Library/Frameworks is where the libraries are. This way, no extra-GNUstep system conf file is needed. It also relieves the user from having to install the conf file and edit it based on where they unrolled the binary dist (unless its done automatically which might clobber a user-installed GNUstep which depends on the file).

This would be fine if apps were all to be run from a fixed location in the hierarchy, but that's not the case, consider any app in the user domain for instance. People object to you telling them they can't put individual apps where they like.

The price of putting apps where you want is to set the LD_* variable. This is not an unreasonable expectation and relieves much of the kludge of other suggestions.

I don't understand what you are saying here ... it does not seem to relate to the point. Perhaps this implies that you did not understand what I was saying either :-)

I was saying that it's not possible to rely on relative paths to locate resources ... since people can install applications wherever they want, the resources those applications need won't be in fixed locations relative to the applications. I think it should be obvious that unless we constrain users to only install applications in fixed locations, we cannot make assumptions about the locations of shared resources based on the application locations.

This discussion has therefore been about deciding the simplest way to determine the locations of resources ... our standards put them in system, network, local, and user domains. within each domain we have a standardised layout so that things can be located within the domain. The defaults system is a slight exception in that some people have not wanted defaults stored at a fixed location in the user domain. The idea is to use a simple config file to specify where the defaults database and each domain is located. That means the only bit of information an application has to be told is the location of the config file (and LD_LIBRARY_PATH). If applications are launched by means of a script/tool (like openapp), all that tool has to be told is the location of the config file.

reply via email to

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