Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Per compiler custom variables not expanded?
MortenMacFly:
Dear all,
I'm having a problem with the custom variables that can be setup per-compiler. I'm currently evaluating the Intel compiler which requires some environment variables to be setup (e.g. "ICPP_COMPILER90", "INTEL_SHARED" and "INTEL_LICENSE_FILE"). I thought if I setup them in the compiler setup as custom variables they would be set before the compiler is called thus the compiler can access them. But unfortunately if I try to compile a hello world application I get the an error that the variable "INTEL_LICENSE_FILE" is not setup. This means that these variables are not expanded as environment variables. It would be great if these variables were really expanded to environment variables before calling the compiler/linker commands. I think that's how it should be but it doesn't seem to work.
...or am I doing something wrong?
With regards, Morten.
Ps.: I'm pretty sure that I've asked this again but when seaching I only found http://forums.codeblocks.org/index.php?topic=1672.0 which doesn't exactly describe the problem.
Pps: Does someone know where these variables are applied? Maybe I can implement/fix this myself?
MortenMacFly:
Dear all,
I found where and how to implement this feature. For anyone requiring the same here is the patch:
--- Code: ------ src/plugins/compilergcc/compilergcc.cpp (revision 2420)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -633,8 +633,34 @@
"This can't be good. There may be problems running "
"system commands and the application might not behave "
"the way it was designed to...");
+
// wxGetEnv("PATH", &path);
// Manager::Get()->GetMessageManager()->Log(m_PageIndex, "PATH set to: %s", path.c_str());
+
+ // apply the env vars for this target
+ StringHash vars = CompilerFactory::GetCompiler(m_CompilerId)->GetAllVars();
+ if (!vars.empty())
+ {
+ StringHash::iterator it;
+ for(it = vars.begin(); it!=vars.end(); ++it)
+ {
+ wxString var = it->first;
+ wxString var_value = it->second;
+ wxString old_value;
+
+ // apply only if not already set (do not overwrite existing variables)
+ if (!wxGetEnv(var, &old_value))
+ {
+ wxSetEnv(var, var_value);
+// Manager::Get()->GetMessageManager()->DebugLog(_T("Applied environment variable %s with value %s..."), var.c_str(), var_value.c_str());
+ }
+// else
+// {
+// Manager::Get()->GetMessageManager()->DebugLog(_T("Environment variable %s not applied."), var.c_str());
+// Manager::Get()->GetMessageManager()->DebugLog(_T("(Environment variable %s is currently set to %s.)"), var.c_str(), old_value.c_str());
+// }
+ }
+ }
}
void CompilerGCC::SetEnvironmentForCompiler(const wxString& id, wxString& envPath)
--- End code ---
Please note that this patch:
1.) only expands compiler custom variables to environment variables and
2.) does not expand a variable that already exist in the environment.
This is on purpose but might be changed if someone requires a different solution.
With regards, Morten.
Ps.: To the devs: Do you think this makes sense? I could improve the patch to save old environment variabes and re-apply the old settings ones the compiler command is issued (similar as it is done with the PATH environment variable). But before I would like to know whether you agree, or not.
Edit: Updated the patch to be more convenient.
MortenMacFly:
...by the way: I found the other post I was refering to:
http://forums.codeblocks.org/index.php?topic=2147.15.
Anyway: For me the problem is solved. Maybe that feature is worth considering in general in the future.
With regards, Morten.
thomas:
Applying custom variables to the environment is something we moved away from around December/January. The main reason was being efficiency (4x overall speedup). In the old days, all custom vars were applied to the environment (possibly overwriting existing variables!) by the compiler plugin and then the macros manager read them back one by one to replace the paths. Generally applying all variables to the environment again does not seem like a good idea to me.
As it happens, you already asked for the same thing in January (regarding the QNX compiler), and I proposed a simple scheme for applying certain variables to the environment on January 26, but nobody seemed to like it. I remember it was even called a "hack" (which it wasn't).
Anyway, since nobody liked my idea and everyone wanted a fancy GUI solution and extra state being written to the project file, I said to myself "Very well, I care not. Let's see who comes up with an implementation then." :)
A possible issue with your patch may be that you modify the compiler plugin which could soon be widely obsoleted.
Also (though I believe no harm is taken) the constraint "only defined for the compiler" may not be achieveable, since the new compiler framework does not know what a compiler is, it only knows stages.
Something that could indeed work fine might be adding an option to define per-compiler environment variables independently of custom vars. You never change those variables anyway, right? :)
EDIT: Aha, I see you found that old post, too :)
MortenMacFly:
--- Quote from: thomas on May 08, 2006, 04:18:17 pm ---Something that could indeed work fine might be adding an option to define per-compiler environment variables independently of custom vars. You never change those variables anyway, right? :)
--- End quote ---
Mmmmh... so you really mean another tab in the compiler setup, right? In general this sounds good to me. I'll think about that.
In addition: It might be interesting to have that feature per project/taget as well. Why? For testing purposes. A lot (especially linux applications) use environment variables... it might be helpful... or maybe as a command-line option for the console-runner...
--- Quote from: thomas on May 08, 2006, 04:18:17 pm ---EDIT: Aha, I see you found that old post, too :)
--- End quote ---
Yepp... I knew we had talked about that but I typed in the wrong keywords to search for in the first place... ;-)
With regards, Morten.
Navigation
[0] Message Index
[#] Next page
Go to full version