[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep-make and NSPathUtilities patch
From: |
Sheldon Gill |
Subject: |
Re: gnustep-make and NSPathUtilities patch |
Date: |
Thu, 29 Jan 2004 13:20:00 +0800 |
User-agent: |
KMail/1.5.93 |
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_
- gnustep-make and NSPathUtilities patch, Sheldon Gill, 2004/01/28
- Re: gnustep-make and NSPathUtilities patch, Pete French, 2004/01/28
- Re: gnustep-make and NSPathUtilities patch, andre levy, 2004/01/28
- Re: gnustep-make and NSPathUtilities patch, Adam Fedor, 2004/01/28
- Re: gnustep-make and NSPathUtilities patch, Chris B. Vetter, 2004/01/28
- Re: gnustep-make and NSPathUtilities patch,
Sheldon Gill <=
- Re: gnustep-make and NSPathUtilities patch, Alexander Malmberg, 2004/01/28
- Re: gnustep-make and NSPathUtilities patch, Nicola Pero, 2004/01/29