User forums > Help
Setting of OS variables possible?
takeshimiya:
--- Quote from: MortenMacFly on January 26, 2006, 07:24:17 pm ---On second thoughts: Isn't this a compiler specific (and not project/target specific) problem? If so, would it make sense to have this setup per global compiler only, thus a page/section on the global compiler setup? Does that make sense???
--- End quote ---
I think so. The "Expose these vars to the environment" is understandeable.
If you have to teach users to use an asterisc for that, y'know, no one will use it, because they will not know.
Introducing new syntax (asterisc) only for this reason seems like a hack to me.
Game_Ender:
--- Quote from: MortenMacFly on January 26, 2006, 07:24:17 pm ---On second thoughts: Isn't this a compiler specific (and not project/target specific) problem? If so, would it make sense to have this setup per global compiler only, thus a page/section on the global compiler setup? Does that make sense???
--- End quote ---
I am bringing this up because your new pluggin got me thinking again. This is really a target specific issue. It is not uncommon for programs to use custom environment variables to determine the location of configuration or data files. During development you might have several sets of these, one you used for debugging, one for release etc. Being able to set these on a target level is key. I am going to implement the wxCheckListBox idea and submit a patch.
takeshimiya:
--- Quote from: Game_Ender on May 10, 2006, 07:18:26 pm ---
--- Quote from: MortenMacFly on January 26, 2006, 07:24:17 pm ---On second thoughts: Isn't this a compiler specific (and not project/target specific) problem? If so, would it make sense to have this setup per global compiler only, thus a page/section on the global compiler setup? Does that make sense???
--- End quote ---
I am bringing this up because your new pluggin got me thinking again. This is really a target specific issue. It is not uncommon for programs to use custom environment variables to determine the location of configuration or data files. During development you might have several sets of these, one you used for debugging, one for release etc. Being able to set these on a target level is key. I am going to implement the wxCheckListBox idea and submit a patch.
--- End quote ---
I agree. The possible levels are:
-At Workspace level
-At Project level
-At Target level
-At Compiler level
-At Global level
-At User level
-At System level
Everything makes sense, but the most useful ones are: at Global level (what the current plugin does), at Compiler level, and at Target level.
MortenMacFly:
--- Quote from: Takeshi Miya on May 10, 2006, 10:34:53 pm ---The possible levels are: [...]
--- End quote ---
Could you tell me, how you will do this? Because setting an environment variable is either system-wide or application wide. In the case of C::B application-wide means within the focus of C::B and all it's child processes. So how do you want to realise e.g. "target-wide"? You cannot select a target. The only possibility I see is to tamper with the build process or the console runner. During the build process you would have to hijack the selection of a new target, set your variable and then unset it upon another target is selected. It's the same way on run-level. Once you choose an application to run you would have to hijack the call of e.g. the console runner, set your environment variable and unset it afterwards. I require this feature too (that's why I implemented it) but when I want to test certain targets I do it target wise - thus: Set the environment variables as required for a target, do my testing and unset / set different for the next target. During compilation it's the same: I usually work on one target only and not on several in parallel. So why would I need so many options where to setup environment variables? I make another suggestion: How to provide a link to the environment variables plugin in the "plugin-menu"? This would allow setting this stuff using a single mouse-click. How about that?
With regards, Morten.
takeshimiya:
--- Quote from: MortenMacFly on May 10, 2006, 11:09:47 pm ---During the build process you would have to hijack the selection of a new target, set your variable and then unset it upon another target is selected. It's the same way on run-level.
--- End quote ---
Well, exactly. For example on a target level there would be a listbox like Yiannis or Game_Ender suggested above.
The actual calling to wxSetEnv would be done either: on target select, or on target usage (eg. when the user clicks Build). And after the next target switch comes, unsetting the previous variables and setting the new ones.
--- Quote from: MortenMacFly on May 10, 2006, 11:09:47 pm ---Once you choose an application to run you would have to hijack the call of e.g. the console runner
--- End quote ---
Another option would be, when building the target, call it like in a batch file or console runner (running multiple programs in the same environment):
--- Code: (qbasic) ---set var=value
gcc --the-rest
--- End code ---
in linux using the export equivalent.
--- Quote from: MortenMacFly on May 10, 2006, 11:09:47 pm ---I usually work on one target only and not on several in parallel. So why would I need so many options where to setup environment variables?
--- End quote ---
Well, I think Game_Ender gave the answer. It is not uncommon to use different env. vars in different targets, for example I have a project that haves targets GCC Release, GCC Debug, VC Release Unicode, etc, and some of the compiler/tools requiere different variables being set.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version