[Top][All Lists]

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

gnustep-make and NSPathUtilities patch

From: Sheldon Gill
Subject: gnustep-make and NSPathUtilities patch
Date: Wed, 28 Jan 2004 14:59:48 +0800

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...

GNUstep now relies on a configuration file to determine paths. The file is
{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
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

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

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

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

2) ~/GNUstep.sh won't be automatically invoked at startup so what do I do
* 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
* 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
- 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.

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.

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:

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.


reply via email to

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