[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GNUstep-packagers] patch for observance of $HOME
From: |
Richard Frith-Macdonald |
Subject: |
Re: [GNUstep-packagers] patch for observance of $HOME |
Date: |
Sat, 7 Aug 2004 09:24:58 +0100 |
On 7 Aug 2004, at 08:13, Sheldon Gill wrote:
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.
I would not use such a system ... it's a strong requirement for rolling
out systems
for clients that the installed system be relocatable as I don't
necessarily know
where the client is going to install the software. It's no use having
my software
relocatable if the gnustep package I bundle with it depends on
hard-coded paths.
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.
But with clients who require easy to install relocatable binary
packages,
this scheme is no good at all ... as usual, a solution which is ideal
for one purpose
can easily be unusable for another.
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.
Yes ... but we need to provide a script to make the job easy for people
who
aren;t using pre-packaged installations where the job is done for them.
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)
I think the whole issue is easily solvable (as I mentioned in an
earlier post) by
having a single environment variable to define the root of the GNUstep
installation
and having make and base deduce all other information from that.
- Re: [GNUstep-packagers] patch for observance of $HOME, Adam Fedor, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Matt Rice, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio Serrano, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Armando Di Cianno, 2004/08/06
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME,
Richard Frith-Macdonald <=
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio M . Serrano Jr ., 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio Serrano, 2004/08/07
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/08
- Re: [GNUstep-packagers] patch for observance of $HOME, Richard Frith-Macdonald, 2004/08/08
- Re: [GNUstep-packagers] patch for observance of $HOME, Sheldon Gill, 2004/08/10
- Re: [GNUstep-packagers] patch for observance of $HOME, Rogelio M . Serrano Jr ., 2004/08/07