[Top][All Lists]

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

Re: GNUstep.sh / env sanity patches

From: John Davidorff Pell
Subject: Re: GNUstep.sh / env sanity patches
Date: Wed, 18 Aug 2004 00:54:16 -0700

On 17 Aug 2004, at 23:22, Richard Frith-Macdonald wrote:

On 18 Aug 2004, at 02:50, John Davidorff Pell wrote:

If GNUstep-installation-one is installed in /usr/local/GNUstep1 and GNUstep-installation-two is installed in /usr/local/GNUstep2, then we need some way of telling one that its in one directory, and the other in the other, hence the need for a specifiable GNUsteprc, right? Actually, i would expect that installation one should have hard coded into it where it lives, since it cannot be easily relocated anyway. This should solve some of the requirements for a GNUsteprc.

I'm very strongly against having a fixed location which cannot be overridden hardcoded into GNUstep. I want to be able to produce a binary software distribution that I can give to a customer on a cd-rom and tell them to install it and run it wherever they like on their machine.

You're talking about a relocatable install.

I think that all such requirements can be fixed this way. If I want to run myTool with GNUstep2 instead of GNUstep1, then I should run /usr/local/GNUstep2/{System,Local,Network}/Tools/myTool anyway, right?

Then you have had to compile two separate versions ... twice as much work. What you should be able to do is take a single binary distribution and simply unpack into the location you want it. Then users of each installation just need to have an environment variable set to say which installation they are using.

This is not important for most people, but it *is* important if you need to roll out binary distributions to customers. If you make a software release which has dependencies on features of a recent GNUstep, you need to distribute the GNUstep system as part of the release. You can't ask your customers to grab the latest GNUstep from CVS, and build it with their own local configuration options before they can install/use the new release.

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

It might be wise to have some init-like method run at the beginning of every app that's linked to -base so that all apps run after that inherit appropriate LD_* vars. This means that when GWorkspace.app launches apps, they work as expected, as well as an app run from the command line will pass on proper vars to its children.



if (message.signature==FUNNY) steal(message.signature); else message=message->next;

Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

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