Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Solution for: Latest changes in HEAD break C::B build

(1/4) > >>

mandrav:
In this thread, there was some talk regarding usage of environment variables in C::B.

I 've made some relevant updates that won't allow anyone to build C::B HEAD unless the following instructions are followed the first time.
First an overview of custom/environment variables in C::B.

You 've probably noticed the "Custom variables" page in global compiler options. There you can add custom variables that can be used in the compiler/linker options.
I 've extended their usage and now they 're set as environment variables when the build process is launched. This enhances the build process a lot, in many ways.
If you take a look at the project options of CodeBlocks-wx.2.6.0.cbp you 'll notice that I 've added the wxWidgets dirs in compiler/linker dirs using two custom variables: WX_DIR and WX_CFG.
This means you can build C::B no matter where you have wxWidgets headers/libs. You just have to set WX_DIR and WX_CFG accordingly.
And the good thing is that you can set those either as custom variables in the global compiler settings or as system environment variables.
Mine are set as custom variables like so:

--- Code: ---WX_DIR=C:\Devel\wxWidgets-2.6.1
WX_CFG=NonUnicode
--- End code ---

WX_DIR must be set to point to the base wxWidgets directory.
WX_CFG must be the same as CFG used when building wxWidgets. If you didn't use CFG, no need to set WX_CFG for C::B.

When you next update C::B HEAD from CVS, you 're gonna have problems though with the build. That's because the project file is expecting these vars declared but because your C::B is older it doesn't know how to handle these vars :/
The solution is to set WX_DIR and WX_CFG as environment variables. After that you can build C::B and once C::B is built and launched you can delete these environment variables and set them as custom variables. You new C::B executable will be aware of these variables now.

Sorry for this slight inconvenience but this had to be done because it adds a lot of versatility in the build process.

As usual, if something's unclear or you have any comments/questions please post them here.

Yiannis.

mandrav:
I forgot to note that custom variables are global C::B settings. The next logical enhancement will be to set them per-project/target.

Yiannis.

darklordsatan:
Getting better every time Yiannis!
One question that remains though is: The original request that originated this, said that env vars should be set per project (and usually during the execution of the program ONLY, i.e they wont be stored in registry as when you add a new value to a given env var through windows "normal" configuration dialog in system properties). Now, what confuses me is this:

1. How is the variable search process? I guess its win32 env var, and if not found then c::b custom var, right?
2. If we take a default env var such as PATH, how can we modify its value through the custom vars dialog, to have the target app read that new value?
Right now, from what I understood, is done in a global scope basis, but you intend to do it per project, ok, but in case Im right about this, the new value will only stay as long as the c::b process is alive, right? After one closes c::b the example PATH variable will have its original value before starting c::b?

Cheers

mandrav:

--- Quote ---1. How is the variable search process? I guess its win32 env var, and if not found then c::b custom var, right?
--- End quote ---

Custom vars are set as environment vars before building. So, no search process is involved :)


--- Quote ---2. If we take a default env var such as PATH, how can we modify its value through the custom vars dialog, to have the target app read that new value?
--- End quote ---

Set a PATH custom var with value "some_other_path;%PATH%". I haven't tried it but I guess it 'll work.


--- Quote ---Right now, from what I understood, is done in a global scope basis, but you intend to do it per project, ok, but in case Im right about this, the new value will only stay as long as the c::b process is alive, right? After one closes c::b the example PATH variable will have its original value before starting c::b?
--- End quote ---

Environment variables setting I mentioned, happens only in the C::B environment and all process launched from within it. When C::B shuts down, no environment variable remains in registry or elsewhere.

Yiannis.

darklordsatan:
Oh I see. Two last questions if you dont mind
1. How do you set the env vars, via win32 API (SetEnvironmentVariable()) or...?
2. This is totally offtopic here, but, what is the exact function that calls the new process?
I was thinking it would be CompilerGCC::Run(ProjectBuildTarget* target) in compilergcc.cpp but given my env vars test I told you about, seemed like not

Cheers

Navigation

[0] Message Index

[#] Next page