discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GNUSTEP_USER_CONFIG problem (Windows)


From: Nicola Pero
Subject: Re: GNUSTEP_USER_CONFIG problem (Windows)
Date: Mon, 5 Dec 2005 17:00:30 +0000 (GMT)

> >> Ah ... I take it back ... I have remembered why it was there ...  
> >> it  was
> >> intended as an aide to development/testing so you can have  multiple
> >> setups running simultaneously using the same libraries/ resources,  
> >> just
> >> slecting between them by setting the environment  variable before
> >> launching the app you are working with.
> >> Perhaps documenting this well (and making the configuration with the
> >> environment variable disabled be the default) would be sufficient
> >> rather than removing the functionality entirely.  I'm not sure   
> >> whether
> >> the feature is more trouble than it's worth?
> >>
> >
> > Actually, I thought it was needed for deployment (esp. for MS-Windows).
> >  If an was build with C:/GNUstep/System but has to be installed in
> > D:/GNUstep/System.  But I'm just theorizing here.

Good point -- some variant of that is quite likely to popup, but probably
not much on MS-Windows (as Richard correctly points out), mostly on Unix
when some sort of package builder is being used ;-)


> Not necessarily ... you can configure so that the location of path  
> are all relative to the config file,  and you can configure so that  
> the location of the config file is relative to the base library ...  
> so as long as the executable can find the gnustep-base dll/so, 
> everything will run.
> 
> For the make package (ie for developers) things are not so neat/ 
> simple ... we have to assume the base library is not installed yet,  
> and we don't want to have to run a tool linked to a base library  
> binary to locate paths anyway ... which is why we have a standard  
> location for the config file at a fixed point in the filesystem.
> Arguably we should make this the standard configuration for  
> executables be relative to the base library for ease of deployment of  
> non-developer systems, but on developer systems it makes sense to try  
> and have the make and base packages be as consistent with each other  
> as possible.

Yes ... obviously on Windows only ;-) as locating gnustep-base on disk is
not necessarily easy on a generic platform, in some cases the root reason
for having a config file is to be able to locate gnustep-base on disk! ;-)

But on Windows, it looks very attractive to have self-relocatable stuff
that you can install anywhere on disk and works.

Thanks





reply via email to

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