Re: gnustep-make and NSPathUtilities patch

[Marc Ordinas i Llopis]

Sheldon Gill wrote:
> 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...
Hi everyone,

We are currently developing some tools using GNUstep on Win32 (yeah, I 
know...), so I thought I'd chip in to tell I really like this proposal.
In fact, we were already studying something like this. It is very 
important for us that our clients can use the apps without having to go 
through a shell script, and requiring the gnustep-make package for just 
running applications is a mess for us.

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

In Win32, maybe the best solution would be to install it wherever 
gnustep-base.dll is, so that accessing it is very easy.

(snip)

Another advantage I see is that with this proposal users can keep their 
normal $HOMEPATH (in Windows XP it always has spaces in it, as 
$USERPROFILE does), as binaries shouldn't have any problem with that, 
and just developers need to change their HOME to a non-spaced dir :)

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

It should be a binary app, if possible.

> 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

and static libraries, at least on Win32 as DLLs go to Tools. Maybe in 
POSIX too, as only .so are required for executing, but this goes against 
tradition having .a and .so at the same dir, so I guess it's not important.

By the way, DLLs need to be in the Tools folder in Win32 because this 
brain-dead system has only just one path, not one for binaries and 
another for libraries.

> 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
     /Libs in Win32
>   /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

Thanks a lot for this work, tell us if you need help porting it to Win32.

Marc Ordinas i Llopis
Tragnarion Studios