Re: GNUstep.sh / env sanity patches

[Nicola Pero]

> > 1. To support libraries and frameworks in the user domain, 
> > LD_LIBRARY_PATH
> > must be set each time the user logs in to include the user domain's
> > library folder in the linker path (you can't set the global paths in
> > ld.so.conf because every user needs different paths!).  This is in
> > conflict with the "no startup scripts" requirements.  The conclusion 
> > is
> > that if you source no startup scripts, you won't be able to put 
> > libraries
> > and frameworks in the user domain.  To be able to do so, you'll still 
> > need
> > to source a script.
> 
> Is this always true?  If I have a framework/library in the user 
> domain, and open application ABC with "openapp" (which is a shell 
> script [atm]), why can it not set LD_LIBRARY_PATH to include 
> "~/GNUstep/Library/LibNeededForABC" before launching the app?  I 
> suppose if openapp was a C program it would have to use putenv() and 
> fork() magic and such to set LD_LIBRARY_PATH and launch the app.

Yes! - you are right :-) - this is possible.  If you started things using
openapp and/or opentool, they could automatically setup the
LD_LIBRARY_PATH at runtime before invoking the app/tool.

I still find that unsatisfactory somewhat - because it's slow, and because
real users would launch application from the workspace manager and tools
from the command line -- in both cases, they wouldn't be using
openapp/opentool.

So they are better off with sourcing GNUstep.sh when they login.

 
> > It would be nice to be able to pass the location of a different file:
> > 
> > * on the command line as a special argument
> > 
> > * as a shell variable
> 
> I support the 2nd more.

The command line as a special argument can probably be dropped, it's not
really needed.  Bad idea, complicating things for no gain.  Blah.


>  My best idea about this, I feel, was 
> following a style like the following to get paths and such: env vars 
> -> conf files -> happy defaults (./configure settings?).  Of course, 
> the conf files should be able to "override" the env vars for 
> GNUSTEP_SYSTEM_ROOT and such.

NB: There will be no more GNUSTEP_SYSTEM_ROOT env vars. :-)

 
> Can we stick with keeping conf files somewhere in /usr/GNUstep/System? 
>   This is set at compile time, and maintains GNUstep keeping it's own 
> FHS, rather than the underlying system.  But this is just a minor 
> point.

The point is that you have a single "native" GNUsteprc file installed
outside the GNUstep layout which describes what GNUstep layout you are
using and how it is setup and where you find the various domains.

I find that having the file describing the layout inside the layout itself
is confusing.

So I strongly prefer /etc for that single config file, or whatever the 
default for the native platform is for configuration files.

It's also easier for humans -- if you are on a machine you don't know and
you want to know where the GNUstep domains are, you look into
/etc/GNUsteprc (or /etc/GNUstep/GNUsteprc or whatever, anyway it's
something in /etc).  If different distributions/setups where configuring
GNUsteprc to be in different locations (and then hardcoding the different
location in the gnustep-base library) it could be hard to find where it is
and so how GNUstep is laid out.

Said that, it should be configurable at compile time so if you want to
have it in /usr/GNUstep, you will be able to have that; you should also be
able to set a shell variable to have it use a different one which
presumably is useful when building in a sandbox to have it use a different
GNUsteprc.

 
> Please, please, please, if we can, support either "INSTALL_ROOT_DIR" 
> or "GNUSTEP_INSTALLATION_DIR" for package building.  At every point 
> where "installing" is taking place in the GNUmakefiles, if those 
> settings are there, they should override GNUSTEP_SYSTEM_ROOT, but 
> solely for the purposes of where make is going to tell the files to 
> install themselves when "install" is called; nothing more, nothing 
> less. :-) [another point that was driving me nuts lately ;-)]

Yes - that is not relevant to this discussion though.  You can set those
on the command line when you invoke 'make', they don't need to go in
config files, as they are specific to that compilation run.