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).
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
