Setting of OS variables possible?

[MortenMacFly]

What would it matter? [...]

Aaaah! I see. I thought the command line is analysed, then the macros from this very command-line are translated/applied and then command is called. If I got it right than first the macros are all translated/applied then (each) command line is computed and the command is called. That's even better. So my objection can be safely ignored.

Would it be a bad time to say I don't agree with the asterisk thing?

Of couse not, but I would be interested in the reason...

Morten.

[mandrav]

With the asterisk specifically, or with the idea as such?

Well, with the whole idea.
I think the most straightforward way is to just add a checkbox in custom variables page, something like "Expose these vars to the environment". So we expose only what the user needs exposed, with his own approval, and we don't add more burden to the MacrosManager...

[Game_Ender]

What about a simple wxCheckListBox ?  Just check to indicate that the variable should become part of the environment.

I think it would be bad to have either them all be on or all off.  Being able to select on a per variable basis offer more flexibility and less chance of conflicts.

On this same note, you should be able to tell Code::Blocks to define some environment variables for when a target is run.  Curently there is no way to do this an programs that need a custom LD_LIBRARY_PATH are hindered.  I have to run a hacked console_runner that invokes the real console runner with the proper environmental variables set.

[thomas]

I like the asterisk idea because it is simple.
You need zero changes to the project file and zero changes to the GUI. The only necessary change would be to iterate through the key-value map once per target change (for example from within the RecalcVars function), applying all elements which comply with iter->first.Last()=='*' to the environment.

If you append another boolean to every variable, then you have to store it in the project file, too, altering its structure. On the other hand, if there is an extra character in a variable's name, then the project file loader couldn't care less.

[MortenMacFly]

What about a simple wxCheckListBox ?

I personally agree with Game_Ender here. I think to apply the expansion to all variables might result in other problems (e.g. overwriting variables by accident). What about to add a checkbox with a clear description to the dialog that appears for adding a new custom variable?

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???

Morten.

Edit: Thomas, that's the second time we were posting in parallel... but I'm always the one that is late... :lol:

[takeshimiya]

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???

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]

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???

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]

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???

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.

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]

The possible levels are: [...]

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]

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.

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.

Once you choose an application to run you would have to hijack the call of e.g. the console runner

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

in linux using the export equivalent.

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?

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.

[MortenMacFly]

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.

Could you give an example for my better understanding? I'm using different compiler/tools that require e.g. an evironment variable LICENSE_FILE being set. I can do this now (switching to another license file). But especially compilers usually have the possibility to provide the information set by an environment variable also through the command line interface...?!
I like the wxCheckListBox idea very much. If (in addition) the plugin is availale through the "plugins" menu directly shouldn't this be enough?
With regards, Morten.