Setting of OS variables possible?

[MortenMacFly]

Dear all,
I have a question: Is it possible to set a specific OS environment variable before running a compiler using C::B? I don't mean the C::B user/compiler/global variables or defines that are used as arguments for the compiler/linker. I really mean the once you set at the command prompt, e.g. the PATH environment variable. If I got it right then C::B runs an external command shell so in general this could be possible.
Why do I want this? In my specific case I am using 2 programs that use the FLEX license manager. One of it is a QNX compiler. Thus the compiler requires a specific environment variable to point to the license file. Unfortunately the variable is called the same for both applications so I have to switch from one to the other. If it would be possible to set his environment variable for the QNX compiler only at compile time in C::B this would help a lot. I always forget to set the variable accordingly before starting C::B. So when it comes to compilation I always have to quit C::B, update the environment and run C:::B again.
Another reason might be environment variables such as INCLUDE or LIB which is set by e.g. MS-DevStudio but others as well. So such things might really interfer if several compilers are installed on a single system.
So again: Is this already possible? Any arguments why not? Any help is appreciated.
With reagrds, Morten.

[mandrav]

So again: Is this already possible?

It sure was.
At some point, Thomas worked on optimizing things in macros/variables replacement (it was necessary) and it may have broken since then. I haven't tested it lately.
Why don't you test it and see?
Normally, all custom variables should be exposed as environment variables.

[thomas]

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.

The reverse does work, environment variables can always be used inside Code::Blocks, but that's not what you want here...

You could set them from a script which runs in pre-build steps, though. What's the Windows equivalent for sh's EXPORT?

[MortenMacFly]

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.
Sorry for that, I'll try now... and reporting back...

Morten.

[MortenMacFly]

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.

Code

SET PATH=%PATH%;D:\Devel\CodeBlocks

:lol:
Thank you very much so far... Morten.

[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]

After that (when the compiler runs)  these settings are lost.

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.

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.

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]

FOO="something"
EXPORT BAR="something else"

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

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.

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

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?

[thomas]

...while searching through C::B how the run of a compiler is done I found
[...]
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?

Yes, 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

I would add the user variables from inside MacrosManager though.

[MortenMacFly]

And here is my proposal:
[...]
How does that sound?

That certainly gives a lot of flexibilty. It also makes re-use of variables possible, so I would fully agree.

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. Thus passing the variable to the compiler might not make sense or even cause an error. But I may be over-sensible or even wrong... and for example G77 supports defines because it translates Fortran into C and than compiles.
Morten.

[thomas]

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...
I only wanted to point out that you could use them for commandline options like every other variable. But you don't need to.
The idea is to apply all variables having an asterisk to the environment whenever switching to a new target (and to look for an asterisk-variable during replacement if no non-asterisk one can be found).
That way, you can still use everything the way everybody is used to.

[mandrav]

Would it be a bad time to say I don't agree with the asterisk thing?

[thomas]

With the asterisk specifically, or with the idea as such?

[MortenMacFly]

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

Morten.

[mandrav]

With the asterisk specifically, or with the idea as such?

Well, with the whole idea.
I think the most straightforward way is to just add a checkbox in custom variables page, something like "Expose these vars to the environment". So we expose only what the user needs exposed, with his own approval, and we don't add more burden to the MacrosManager...

[Game_Ender]

What about a simple wxCheckListBox ?  Just check to indicate that the variable should become part of the environment.

I think it would be bad to have either them all be on or all off.  Being able to select on a per variable basis offer more flexibility and less chance of conflicts.

On this same note, you should be able to tell Code::Blocks to define some environment variables for when a target is run.  Curently there is no way to do this an programs that need a custom LD_LIBRARY_PATH are hindered.  I have to run a hacked console_runner that invokes the real console runner with the proper environmental variables set.

[thomas]

I like the asterisk idea because it is simple.
You need zero changes to the project file and zero changes to the GUI. The only necessary change would be to iterate through the key-value map once per target change (for example from within the RecalcVars function), applying all elements which comply with iter->first.Last()=='*' to the environment.

If you append another boolean to every variable, then you have to store it in the project file, too, altering its structure. On the other hand, if there is an extra character in a variable's name, then the project file loader couldn't care less.

[MortenMacFly]

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

Morten.

Edit: Thomas, that's the second time we were posting in parallel... but I'm always the one that is late... :lol:

[takeshimiya]

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 think so. The "Expose these vars to the environment" is understandeable.

If you have to teach users to use an asterisc for that, y'know, no one will use it, because they will not know.
Introducing new syntax (asterisc) only for this reason seems like a hack to me.

[Game_Ender]

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

[takeshimiya]

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

I agree. The possible levels are:

-At Workspace level
-At Project level
-At Target level
-At Compiler level
-At Global level
-At User level
-At System level

Everything makes sense, but the most useful ones are: at Global level (what the current plugin does), at Compiler level, and at Target level.

[MortenMacFly]

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?
With regards, Morten.

[takeshimiya]

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.

Well, exactly. For example on a target level there would be a listbox like Yiannis or Game_Ender suggested above.
The actual calling to wxSetEnv would be done either: on target select, or on target usage (eg. when the user clicks Build). And after the next target switch comes, unsetting the previous variables and setting the new ones.

Once you choose an application to run you would have to hijack the call of e.g. the console runner

Another option would be, when building the target, call it like in a batch file or console runner (running multiple programs in the same environment):

Code: qbasic

set var=value
gcc --the-rest

in linux using the export equivalent.

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?

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.

[MortenMacFly]

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...?!
I like the wxCheckListBox idea very much. If (in addition) the plugin is availale through the "plugins" menu directly shouldn't this be enough?
With regards, Morten.