discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep.sh / env sanity patches


From: Armando Di Cianno
Subject: Re: GNUstep.sh / env sanity patches
Date: Mon, 16 Aug 2004 12:14:38 -0400

On 2004-08-16 12:00:37 -0400 Richard Frith-Macdonald <address@hidden> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]