User forums > Help
Setting of OS variables possible?
MortenMacFly:
I promised to report back, so here it is:
I tried to use the custom variable approach in the target / project and compiler options. Non of this works, the compiler still complains that the license environment variable is not set. So it seems that (at least on Windows) they are not expanded. Then I tried to use the pre-build options. Of course if I put a "SET XXX=YYY" there this doesn't work (I didn't expected this to work). But when I ran the batch file that intialises the compiler in a command prompt (similar to vcvars.bat from MSVC) it doesn't work eighter. This doesn't suprise, because these settings only apply to the command shell that runs the batch file. After that (when the compiler runs) these settings are lost.
So it seems to me that this functionality is broken... :( Could someone other than me verify, please?
Morten.
thomas:
--- Quote ---After that (when the compiler runs) these settings are lost.
--- End quote ---
This is why I asked what the equivalent for EXPORT is. If you type
FOO="something"
EXPORT BAR="something else"
in a "real" shell, then $FOO will be lost when you close that shell, but $BAR will not. I don't know the syntax to do that under Windows, but there must be something similar.
--- Quote ---So it seems to me that this functionality is broken... Sad Could someone other than me verify, please?
--- End quote ---
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.
In the old days, the compiler would first define all user variables as environment variables, and forget about them. Then, at a later time, it would call the macros manager and request that all environment variables be replaced. This was one reason why it was so slow and why it was so hard to track down bugs.
But hey, we could re-implement that functionality (only for a defined set of variables), it really seems to be useful... :)
MortenMacFly:
--- Quote from: thomas on January 26, 2006, 02:46:36 pm ---FOO="something"
EXPORT BAR="something else"
--- End quote ---
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".
--- Quote from: thomas on January 26, 2006, 02:46:36 pm ---But hey, we could re-implement that functionality (only for a defined set of variables), it really seems to be useful... :)
--- End quote ---
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.
So in the end I believe the possibility to setup environment variables for specific compilers is a feature that is really worth considering. The question is: How to do that? I wouldn't limit the set of possibilities here to a certain set or number of variables because each compiler/project/target might require a different set or override an existing one. I know that if you're using Windows API to start an external process you can specify the environment explicitely and/or you can inhererit from the existing environment settings. Maybe wxWidgets offers a similar functionality? I'll have a look at that...
Morten.
MortenMacFly:
...while searching through C::B how the run of a compiler is done I found in the following lines of code in int CompilerGCC::DoRunQueue():
--- Code: ---#ifndef __WXMSW__
// setup dynamic linker path
wxSetEnv(_T("LD_LIBRARY_PATH"), dir + _T(":$LD_LIBRARY_PATH"));
#endif
--- End code ---
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?
Morten.
Edit: I completely forgot to add: Would it be wrong to apply the custom variables setup by the user at that point using the same way, too?
thomas:
As usual, the hardest part to do in this case would be the user interface... how to do it so people are able to understand and use it, and how to do it without adding 10.000 new dialogs...
And here is my proposal:
We don't change anything at all, but we allow you to define user variables with an additional naming scheme (similar to the '#' global user variables). Let's say we use a trailing '*' as a magic marker. During internal variable expansion, this is just stripped off without any effect - those are plain normal variables. But, in addition, these are added to the environment!
For that to work, all that needs to be done is to iterate through the list of defined variables once per target and apply all the ones ending in '*' to the environment. This should not be hard to get right.
Thus, you could define your variables like this:
MYNAME = morten
MYIDE* = codeblocks
and you could use them as usual:
gcc -D$(MYNAME) -I$(MYIDE)
However, the variable MYIDE would also be applied to the environment.
How does that sound?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version