[Top][All Lists]

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

Re: gnustep-make and NSPathUtilities patch

From: Marc Ordinas i Llopis
Subject: Re: gnustep-make and NSPathUtilities patch
Date: Wed, 28 Jan 2004 11:31:53 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4

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.

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.

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


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

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.

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

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.


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

Marc Ordinas i Llopis
Tragnarion Studios

reply via email to

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