Re: gnustep-make and NSPathUtilities patch

[Sheldon Gill]

On Thu, 29 Jan 2004 10:56, Chris B. Vetter wrote:
> On Wed, 28 Jan 2004 14:59:48 +0800
> "Sheldon Gill" <sheldon@iinet.net.au> wrote:
> You will most certainly get a veto coming the BSD fraction (including
> me) here, as
>
>   1) this should be either /usr/X11/etc/ or /usr/local/etc because it
>      is NOT a system related config file. On BSD, /etc is _only_ for
>      operating system related configs, you (in general) are welcome to
>      put stuff there, but an additional software package _must_not_.
>
>   2) it's not called '.../GNUstep/' but '.../WindowMaker/'
>      as in /usr/X11R6/etc/WindowMaker/
>

Is your veto against the name and location of the configuration file or the 
concept of it?

In regards to the first:

The change uses a defined GNUSTEP_CONFIGURATION_FILE which can be set as part 
of the build configuration so it can be over-ridden to be any file, anywhere 
in the hierarchy that the builder chooses.
(see NSPathUtilities.m, it's defined in that file for the purpose of 
evaluating and testing the patch without requiring changes to the whole 
autoconf set up as well)

My primary goal with these changes is for GNUstep to become more flexible with 
paths and installations.  I'm trying to not mandate a place for anything: no 
imposed file hierarchy for anyone.

As for the second, my reasoning is this:

The way to avoid imposing a path is for software to discover it dynamically. 
That's why NSSearchPathForDirectoriesInDomains was created in the first 
place. The NeXT FHS changed many times and so they realised the need for such 
a mechanism. The Macintosh has long had FindFolder() for path discovery. Even 
MS-Windows has it's own mechanism.

I expose this functionality to the shell via 'gspath' so that shell scripts 
can become similarly path agnostic in a consistent way. The more places that 
are defined through this mechanism the more "agnostic" the system becomes 
because these places can easily be changed without breaking anything.

Any path discovery system we put in place needs a definition in some place.
* Instead of hard-coding it into the libraries I've made it a text file. This 
makes it easy to change for anyone without any special tools and without 
requiring re-compiling anything.
* By sharing one definition it avoids package schizophrenia.

> You assume too much.

I'm trying to change the system so that it assumes _less_