Re: GNUstep.sh / env sanity patches

[Armando Di Cianno]

On 2004-08-16 12:00:37 -0400 Richard Frith-Macdonald 
<richard@brainstorm.co.uk> wrote:
> Am I missing something here?
>
> Is there really a big problem because a packaging system won't let 
> GNUstep 
> read/write stuff while building?
>
> No system could be so strict it prevents all filesystem access ... 
> the 
> compiler would fall over if it can't write temporary files,
> so the packaging system must provide a version of /tmp somewhere.

Yes, the "temp" directory is synonymous with the "sandbox" ... the 
GNUmakefile can "rm -Rf /" all it wants to, or try to create a billion 
sparse files, any things (hopefully!) won't go to heck for the 
user/installer.

> So all you 
> should need to do is to point GNUstep to use this temporary directory.
> Basically, the same process I outlined earlier today as a way to 
> provide user 
> defaults for a non-existent user.

Yes your previously mentioned _method_ was correct, but it failed to 
completely cover my problem issue.  Many of the GNUmakefiles (I think 
the actual included *.make pieces from gnustep-make make certain (bad) 
assumptions about use of GNUSTEP_SYSTEM_ROOT versus 
GNUSTEP_INSTALLATION_DIR / INSTALL_ROOT_DIR.  Basically, if I 
specificy GNUSTEP_SYSTEM_ROOT=/not/real/install , then there's no 
GNUsteprc.  If I _put_ the GNUsteprc in there (to override where to 
write defaults), then things start to work again ... until the 
GNUmakefile can't find all the system makefiles.  Use of 
GNUSTEP_MAKEFILES does not seem to alter this behavior either.

Use of my (albeit wrt to memory usage bad) patches, where I grab 
GNUSTEP_USER_ROOT and GNUSTEP_DEFAULTS_ROOT from the env, but _still_ 
adhere to the real system GNUsteprc overrides, things can (and do, I'm 
using them right now) work.

The "fall through" method of env -> files -> happy defaults I 
mentioned would work, I believe, but right now, because each and every 
method of specifying locations doesn't completely cover the other, 
there exists impossible walls becuase suddenly the problem exists 
multi-dimensionally and not just flatly.

__armando