On 5 Dec 2005, at 13:33, David Ayers wrote:
Richard Frith-Macdonald schrieb:
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.
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.
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
