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)

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]

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?

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

EDIT: Aha, I see you found that old post, too

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.

[yop]

AFAIR when I added the Intel compiler support, that global variable was set by the compiler installation, but maybe I 'm wrong as the support for that compiler was added somewhere around November (?) and the global variables expansion was still there. My demo license for icc in windows has expired so I can't take a look at it. Also I haven't yet installed it in my (brand new) gentoo box but until a month ago it worked on a regular basis on my suse installation without any problems.

[MortenMacFly]

AFAIR when I added the Intel compiler support, that global variable was set by the compiler installation, [...]

No, you are right. It is set during installation. So there is nothing wrong with the Intel compiler plugin. But I'm working on a terminal server that resets all user-settings made after log-out for security reasons. So this environment variable is lost everytime I log off. I've also "installed" the Intel compiler by simply copying it and not using the installer (I don't have the right to run a setup on that machine). So I see basically 3 requirements for the implementation of an "environment - variables - setting - thingy":
1.) You want to set environment variables by hand (e.g. you want to force overwriting an existing one, e.g. LIBS or INCLUDES.)
2.) You have conflicting environment variables for compilers and/or tools, e.g. "LICENSE_FILE" is used by quite some tools - so this would result in 1.) basically.
3.) You want to run tests with your application that uses (expands) environment variables.

On my way home I thought about that problem any further. I think it shouldn't be a per-compiler option. Maybe it's best to implement this feature one-time only under "settings" and maybe as an addition to the "runner" options. This means e.g. the console runner would be in charge for setting environment variables provided via a command line option (e.g. console_runner -Emy_env=my_value or similar...). Setting up such variables would then be a per-project setting... just line the command line passed to the application.

Any comments on that?

With regards, Morten.

[thomas]

Actually, why don't we just make a environment variables plugin? 

When the plugin loads, it sets whatever variables you have specified, so they are always defined as long as Code::Blocks runs.

[MortenMacFly]

Actually, why don't we just make a environment variables plugin? 

Well... sounds quite simple and is (indeed) a good idea. Are you going to implement this within 5 minutes again (like the autosave plugin)? Otherwise I would volunteer and give it a try... but it might take significantly longer... ;-)
With regards, Morten.

[thomas]

Dinner first   But if you like, go ahead

[MortenMacFly]

Dinner first   But if you like, go ahead

Ok, I'll take the chance. But when I say "significatly" I mean maybe a few days... you know... UML design first... ;-)
But seriously: Let me try... you could read a book instead... a big one... :lol: :lol: :lol:
With regards, Morten.

[takeshimiya]

Actually, why don't we just make a environment variables plugin? 

I was about to submit a FR the other day about an env_vars plugin, it's something really needed.
wxPropertyGrid fits perfect for the case.

[MortenMacFly]

I was about to submit a FR the other day about an env_vars plugin, it's something really needed.

...please be patient... I'm already woking on it... ;-)

[takeshimiya]

I was about to submit a FR the other day about an env_vars plugin, it's something really needed.

...please be patient... I'm already woking on it... ;-)

Great, eagerly waiting.

[yop]

Me too. If you change the QTDIR env var you can switch between Qt versions on the fly. It's obvious that I 'm intrested