Currently you can set environment variables for all of a code::blocks configuration, and in the project properties set them as default in the EnvVars Options tab. This has a number of problems:
These issues make environment variables fairly useless, instead needing launch scripts to perform the same functionality.
What would be better: A per-target list of environment variables that's stored in the project, for both real and virtual targets.
That would be especially useful when working with debugging systems controlled by environment variables - for instance, to get a stack trace from the undefined behaviour sanitiser, you need to export UBSAN_OPTIONS=print_stacktrace=1
and it would be nice to be able to do this just for the debug target, on a project level.
Have you considered using build options -> custom variables?
They should work fine for storing both the variable name and the value in the project.
And they will be the same on every machine. The idea of the env variables is to allow different users to set different values.
Also the rules for replacing them should be the same as for env variables, so you can use them the same way.
Last edit: Teodor Petrov 2016-05-24
That's not what I mean - unless I've misunderstood you, that won't give me a way to set actual system environment variables, not for use within codeblocks but for use by the program being executed. I don't need them at the build stage, but when running the compiled program.
Or is there a way to use that functionality to do what I need somehow? If so, can you explain exactly how I'd export that variable for when the compiled binary is executed for a specific target?
I'm not sure adding env vars per target will be a reliable solution for your problem, because I doubt the env vars are set correctly during every build -> run. But this is a guess that have to be verified.
I also don't see a way to export env vars using scripting, but this could be added easily. Not sure if it will be more reliable.
You can try running something like:
but this will get annoyingly complex pretty easily. So my best answer is use a shell script and store it in the repo. Then set it as the host app that will be run in Project -> Set program's argument -> Host application. This will be reliable and easy to modify. It should support Build -> Run also it should work fine in debugger sessions.
Okay, I've never seen this option before. It looks like it could be a workaround to do what I need... if it only worked: https://sourceforge.net/p/codeblocks/tickets/362/
And since you mention
bash -c
calls, this might be a good time to remind you of bug https://sourceforge.net/p/codeblocks/tickets/339/ which means that it's impossible to run commands with nested quotes usingbash -c
- which has caused countless headaches with custom build commands.