Re: GNUstep.sh / env sanity patches

[Nicola Pero]

> 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? 

That will be possible.  My plan is to keep the current features/philosophy
still available.  I do want to be able to have multiple traditional
gnustep installations myself.

You'd have to configure GNUstep1 and GNUstep2 with the appropriate set of
gnustep-make ./configure flags (we need to write clear documentation with
examples for the common cases, anyway assuming we have that).

Then, if you want to use GNUstep1, you do

. /usr/local/GNustep1/System/Library/Makefiles/GNUstep.sh

and here you are, GNUstep1 is being used.

If you want to use GNUstep2, you source the GNUstep2's GNUstep.sh script
(potentially first sourcing GNUstep-reset.sh if you are in GNUstep1 at the
moment).

That's what you wil see as a user.  It's nothing different from what you
see now.

Behind the scenes, there will be a GNUsteprc file installed inside
GNUstep1 and one inside GNUstep2.  GNUstep.sh will load the paths from
GNUsteprc instead of having them hardcoded into GNustep.sh itself.  
GNustep.sh will look for a local GNUsteprc before the system /etc one.  
When you install gnustep-make it will only install a single GNusteprc
either in /etc or in the local GNUstep installation dir.  That's all an
implementation detail though.  It will set the env variable needed by
gnustep-base to detect the GNUsteprc located in the non-standard location.  
It will set the GNUSTEP_MAKEFILES variable which is the only variable
needed to execute the makefiles if you are compiling.  It will also set
PATH, LD_LIBRARY_PATH, CLASSPATH, etc.

But how that works is quite an implementation detail -- why do you care
how it works internally?

You can also have your own simplified GNUstep.sh script, if you want, 
which just sets 

GNUSTEP_RC=/usr/local/GNustep1/System/GNusteprc
GNUSTEP_MAKEFILES=/usr/local/GNustep1/System/Library/Makefiles
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/GNustep1/System/Library/Libraries:/usr/local/GNUstep1/Local/Library/Libraires"
PATH="$PATH:/usr/local/GNustep/System/Tools:/usr/local/GNustep/Local/Tools"

if you add those lines to your shell login script, or if you just put them
into a script, you can switch your gnustep installation by just executing
this, which is certainly simpler than what GNustep.sh currently does.

This is more or less what you suggested/wanted to have below, when you say
that LD_LIBRARY_PATH is really the only variable which needs to be set.


> Actually, i would expect that installation one should have hard coded 
> into it where it lives, since it cannot be easily relocated anyway. 

Sure.  That 's exactly wht the GNUsteprc installed inside installation 1 
will do -- hardcode the paths of where everything is.

The reason GNusteprc is nice is that the paths are hardcoded, but in a
text-editable file with a trivial format, so you can actually change them
if you know what you are doing :-), or you can just look at them to see
what the filesystem layout is ... since we'll be supporting stuff like
installing libraries into /usr/lib for the people who need that, it might
be useful to be able to look at the hardcoded paths; if they are hardcoded 
into the object files it would be a lot more difficult to view them and 
edit them. 


> For developers, there would continue to need to be a GNUstep{rc,.sh} 
> script to source, but this is something that I see no way at all to 
> prevent.

That I'd really like to prevent though.

GNUSTEP_MAKEFILES=/opt/GNustep/System/Library/Makefiles

should be all you need to compile stuff. :-)

That's not quite it if you think seriously about it, because if you're
running a multi-architecture system, you need GNUSTEP_HOST_CPU etc to be
set properly too, and you don't want to compute them everytime you execute
a makefile for speed reasons.  If we are flattened (presumably what
everyone is normally using nowadays) that's irrelevant, but if we are not,
I have to manage that too.  Presumably if multi-architecture is disabled
(currently the default and what most users even if non-flatteneed will be
using), we'll just cache those variables in GNUsteprc too.  Basically,
GNusteprc will also contain GNUSTEP_HOST_CPU=ix86 etc.  That will be
quick.  If multi-architecture is on and non-flattened is on too (that
means we have support for flat binaries turned on, plus the makefiles and
base libraries are from a net shared volume which contains fat binaries
and is used by multiple installation with different cpu/os/arch installed
on them) presumably that caching would still work if every machine has got
its own GNUsteprc in /etc rather than a single shared one mounted from
remote.  That's an additional reason to have GNusteprc in /etc.  If even
GNusteprc is mounted from remote, we're in performance troubles with the
makefiles, but that looks unusual enough that we can probably recompute
host, cpu and arch at every makefile invocation, or better compute them
once then export the result to all sub-make invocations, it will be
slightly slower but well it looks like unusual enough (and you'll still be
able to work around that slowness by setting GNUSTEP_HOST_CPU manually).

Anyway I imagine nobody really cares about all those details (except for
the conclusion, which is that it can be made to work), sorry for the long
paragraph, thanks for your comments.

Thanks