Re: [GNUstep-packagers] patch for observance of $HOME

[Sheldon Gill]

On Fri, 6 Aug 2004 22:26, Armando Di Cianno wrote:
> On 2004-08-06 04:36:01 -0400 Richard Frith-Macdonald
>
> <richard@brainstorm.co.uk> wrote:
> The latest incarnation of my quest to resolve my issues, has me
> convinced that if across the board "where to write defaults?" issue is
> addressed the ideal process for discovering paths would go like this:
>
> 0) env vars - "Did the user configure the instance of this app?"
> 1) static files - "Did the system maintainer configure the default
> behavior of this app?" (.GNUsteprc does this to some extent)
> 2) "happy defaults" - "App says, `I'm alone and frightened, what do I
> do?`"

This is what the NSPathUtilities patch does. It sorts out most of these 
issues.  Using that, absolutely _no_ environment variables are required to be 
set. It does the (1) static files part by having a hard coded location for 
the startup file. This is set during the build and is a design decision to do 
it this way.
The (2) defaults are, again, set during the build phase.  There is even 
provision for the library to be built to go straight to (2), ie use hard-code 
only.  That is a good choice for a package on a fixed FS layout.  Under such 
a system there is only one place for things to go and so no decisions really 
need to be made.

> > We also
> > need to modify PATH and LD_LIBRARY_PATH etc to allow GNUstep programs
> > to be
> > simply run from the unix shell.

Sort of. There are choices here.
LD_LIBRARY_PATH is needed only if the libraries are put somewhere other than 
the standard locations for the platform. For package maintainers this isn't 
an issue because the libraries are supposed to go somewhere.
PATH isn't so much of an issue. It can be circumvented by using a launching 
tool which knows about GNUstep locations (either hard-coded or conf file).
That means you'll have to use something like:
gslaunch Ink.app {for applications}
gslaunch make_services {for tools}
which really isn't so hard.
There is also the possibility of adding sym-links into {whatever}/bin
How it should be done is a packager choice for the platform.

> many ways to configure the GNUstep env in subtle ways is, well, a
> bother to me, but potentially a bother to all users.

The GNUstep env is a great thing if you know how it fits together. Really, 
though, it should only be of concern to those wanting to build and run -core 
in a sandbox.

Here is the crunch.  Getting -make to behave properly in this scheme requires 
a few modifications. Some of these should, IMHO, be made anyway because there 
is currently a certain level of linkage between -make and the others (-base, 
-gui, -back) which shouldn't be there. For example, you configure the choice 
of back integration in make, not in -gui. Or that you choose your path layout 
in -make instead of in -base.

Currently, you configure the path layout you want for -base in -make. Which 
causes all sorts of problems if you're trying to have multiple builds on the 
same machine. You end up with multiple installations of -make configured for 
the different sandboxes and sourcing various GNUstep.sh for each.

I've gotten around that problem by having a gspath tool which can discover the 
path correctly for the platform and can be told what path to use for a 
particular sandbox. (Okay, I'm doing that with an env var but that's because 
there is no getopt on Win32 standard and importing existing code for it is a 
licensing issue I don't want to deal with right now)


Regards,
Sheldon