gnustep-make and NSPathUtilities patch

[Sheldon Gill]

Hi all,

I've looked into the changes implied in gnustep-make by my NSPathUtilities
patch and created a solution which I think is right. This is the proposal,
uncluttered by patches...

THE KEY CHANGE:
GNUstep now relies on a configuration file to determine paths. The file is
'/etc/GNUstep/GNUstep.conf'
{a conf file is the Unix/POSIX thing to do. The directory is already there
for Window Maker. We just use it}
Since this is sufficient for gnustep-base to determine it's paths there is
no need to source GNUstep.sh or even have the gnustep-make package
installed.
The configuration file is sufficiently flexible to allow GNUstep to
basically accommodate most file heirarchy standards.

GNUstep-base changes
====================
* Although you still need gnustep-make to develop, it is no longer a
requirement for the installation of gnustep-base. This allows distributions
to package -base independantly so users can install applications without
requiring any development tools. See previous posts...

GNUstep-make changes
====================
* Two tools are installed in '/usr/bin' so they're on everyones path:
gsmake, gspath
* gspath takes one argument and returns a path for that specifier (eg:
`gspath system` is "/usr/GNUstep/System")
* gsmake is just a wrapper script that sources setstepenv and then invokes
make.

To make anything GNUstep you have two choices:
1) use 'gsmake' instead of 'make' and leave everything alone.
2) Source GNUstep.sh, same old, same old

Changed files
-------------
GNUstep.sh     Now uses gspath

New files
---------
gspath               Deprecates 'user_home' for new functionality
gsmake             Properly sets the environment variables and invokes make
setstepenv         Ex-main part of GNUstep.sh script which sets required
variables

New man pages
-------------
gspath(1)          Tool to determine paths
gsmake(1)        Makes sure the environment is properly set before invoking
make

FAQ
===
1) Sourcing GNUstep.sh is no longer required. Users aren't forced to run
anything at startup, so when do you run make_services?
* Choose:
(a) when a new service or app is installed. Perhaps should be done
automatically via "gsmake install".
(b) from .bashrc alikes
(c) in your .xinitrc
(d) workspace or other desktop layer applications should be responsible (my
pref)

2) ~/GNUstep.sh won't be automatically invoked at startup so what do I do
instead?
* Your .bashrc or whatever is there anyway so use that instead. You can
always call it from there if you really want to keep it separate.

3) If gsmake has to set the environment every time, won't that slow things
down?
* Yes, but not so you'd really notice. If it bothers you, GNUstep.sh is
still around for sourcing the old way.

4) Why bother with gsmake then?
* gsmake is great for most users. If you get source for a stable application
and only want to build it, gsmake is the tool for you. No worries about
setting variables or sourcing scripts correctly. No complications in your
environment. Just do {get <source>, un-archive, gsmake, gsmake install}

5) What about PATH and using tools from the command line?
* Consider
- Applications can find tools themselves without setting $PATH so that isn't
relevant.
- Most "users" won't want access to tools from the command line.
- Developers are savvy enough to edit .bashrc alikes
- System administrators can add the paths for any and every login they want
IMHO this is not for GNUstep to stipulate an answer for.


OPEN QUESTIONS
===============
1. GNUstep installation should set up a GNUstep.conf file if needed. I have
a set for different platforms. That's easy. The question is which package
should be responsible for it's set up or installation?

2. It's nice to have a tool to open any installed GNUstep application. Let's
call it $open.app$ for arguments sake. Should we install $open.app$ into
/usr/bin as well?  (I think so. It's a tool for all users.)

Alternatively, we require $GNUSTEP_SYSTEM_ROOT/Tools/$LIBRARY-COMBO in
everyone's path in order to use tools from the command line.

QUESTIONS-FHS
==============
If the Developer sub-tree is for things of relevance only to Developers
(which is the NeXT/Apple way)
* Headers should go here
* So should all API documentation
* and Applications specifically for development

Where does the Makefiles package really go?
* It's for developers. It should go into the Developer sub-heirarchy
- thus it should go into $GNUSTEP_SYSTEM_ROOT/Developer/Makefiles

Proposed Developer sub-heirarchy:
/System
  /Applications
  /Developer
    /Applications
      /Gorm.app
      /ProjectCenter.app
    /Documentation
      /Base
      /Gui
      /Back
    /Headers
    /Makefiles
  /Library
  /Tools

I'll even update make/Documentation/filesystem.texi...

Another advantage of this layout is that you could drag install developer
tools from one machine to another.


Regards,
Sheldon