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: Richard Frith-Macdonald
Subject: Re: GNUSTEP_USER_CONFIG problem (Windows)
Date: Mon, 5 Dec 2005 10:53:10 +0000


On 5 Dec 2005, at 07:50, Lloyd Dupont wrote:

(Remark: Richard, I haven't yet investigate your answer but here is another problem).

Im trying to use the GUSTEP_USER_CONFIG env var in my deployment scenarion.
The fact is: using environment variable is inapropriate.

=== Because ==
1. if I put the env var in the system settings it's quite possible user screw up everything by modifying env are (either accidentally (because of an other app?) or on purpose)
2. I can't set the environment variable in the app shortcut
============

So I don't set-up any environment variable but in my application's main() function I "try" to setup the environment like that:

char** env = { "GNUSTEP_CONFIG_FILE=F:/lilou", NULL };
[NSProcessInfo initializeWithArguments: argv
                                 count: argc
                           environment: env];

It used to work (for GNUSTEP_SYSTEM_ROOT)
It's not working!
What's that!
What should I do!

While you have probably been advised that you could use that method as a hack/workaround for some situations, it's not intended to be used to change environment variables ... it's supposed to supply information in the case where some system specific bug/problem prevents that information from being obtained automatically. I've hacked in a 'fix' in CVS so that the method again overrides the automatic setup on mingw32, but I'm not sure that's the correct thing to do... so I'm not guaranteeing it will continue to work.

It really drives me mad...
Isn't there a (C/programatic) variable somewhere I could edit (like the NSLog_printf_handler or NSException_handler). Instead on relying on environment variable kind of hack which stop to work (silently) after a few version?

in fact is there a programatic way of accessing this parameters!

I'm over fed-up with environment variable.
When an environment stop working (because of new developement) nothing warn the developer (I mean the compiler don't know). Its application simply stop working without warning, without message, without cause.

I think I could safely say now that environment variable are inherently evil and should not be the only configuration method. A programatic interface should exist to fix any problem!
In this case a programatic way to set GNUSTEP_CONFIG_FILE.

When Nicola and I designed the new config stuff, we tried to make it extremely flexible while keeping it really simple. I'm not sure why we left in the option of using an environment variable to specify the location of the config file ... and I think you have convinced me that it's an annoying complexity and should be removed.

Of course, you don't need a programmatic way to set GNUSTEP_CONFIG_FILE ... you just set it when you build the make or base libraries using --with-config-file= It's something that needs to be set for the make package and for the base library, not for an individual application (if an app needed that level of isolation from other apps, it would be bundled with its own copy of the core libraries).







reply via email to

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