So again: Is this already possible?
Normally, all custom variables should be exposed as environment variables.Umm... no, they sure are not. Remember, this was the one thing that caused so much grief.
Normally, all custom variables should be exposed as environment variables.All right! I didn't even try because the dialog states "These variables can be used in compiler and/or linker options." So I didn't get that they are expanded as environment variables, too! So I thought it's only an option to the compiler/linker.
You could set them from a script which runs in pre-build steps, though.Alright, so I see there are several solutions... I feel stupid now... :oops:
What's the Windows equivalent for sh's EXPORT?It's SET, e.g.
SET PATH=%PATH%;D:\Devel\CodeBlocksAfter that (when the compiler runs) these settings are lost.This is why I asked what the equivalent for EXPORT is. If you type
So it seems to me that this functionality is broken... Sad Could someone other than me verify, please?No, it is not broken. It is not implemented. The information that all user variables are exported is not correct. That used to be the case a long, long time ago.
FOO="something"Ok, so I got that wrong. As far as I know there is nothing similar (at least not as simple as "export"). If you setup another environment variable in the properties of "My workplace" they are applied system-wide as soon as you hit "OK". If we were able to figure out what Windows does exactly do then we were done. But (I'm sure you know) all running applications still keep the environment as they were started. The new environment settings apply only to applications you start after "OK".
EXPORT BAR="something else"
But hey, we could re-implement that functionality (only for a defined set of variables), it really seems to be useful... :)I believe that this would be a very neat feature. A lot of commercial compilers require specific environment variables to be setup. And from my personal daily work I can tell you that this is (excuse my french) but a pain in the ass. Because such environment variables conflict a lot. And I think the solution as MS does with a vcvars batch file is not very efficient.
#ifndef __WXMSW__
// setup dynamic linker path
wxSetEnv(_T("LD_LIBRARY_PATH"), dir + _T(":$LD_LIBRARY_PATH"));
#endif
...while searching through C::B how the run of a compiler is done I foundYes, that's exactly how it is done. I don't know why that specific variable is applied to the environment, either the compiler needs it for some reason, or it is a fossile... as Yiannis ;)
[...]
Isn't this something like we are talking about? If I got that right than this statement applies to the instance of C::B. Thus if I run a process (compiler call) afterwards this variable is set because it's inherited from C::B. Am I right?
And here is my proposal:That certainly gives a lot of flexibilty. It also makes re-use of variables possible, so I would fully agree.
[...]
How does that sound?
The only drawback I see that could cause problems is if a compiler doesn't support defines/includes etc. I know this sounds strange, but if you think about languages other that C and C++ (e.g. Fortran) this might happen.What would it matter? If it is defined, then it is exported, whether you use it on the commandline or not... :)
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...
With the asterisk specifically, or with the idea as such?
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???
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???
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 (http://forums.codeblocks.org/index.php?topic=3061.0) 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.
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?
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 var=value
gcc --the-restI 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.
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...?!