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

[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

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]

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

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

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?

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

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?

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

[mandrav]

1. How do you set the env vars, via win32 API (SetEnvironmentVariable()) or...?

wxSetEnv() to be cross-platform

2. This is totally offtopic here, but, what is the exact function that calls the new process?

CompilerGCC::DoRunQueue() is actually spawning processes. CompilerGCC::Run() and the likes, just fill the commands queue that is processed by CompilerGCC::DoRunQueue().

Yiannis.

[darklordsatan]

Ok, thanks! BTW, nice "666" post count

[mandrav]

Hehehe, and I was replying to DarkLordSatan with my 666th post  :twisted:

Yiannis.

[David Perfors]

I have troubles with this when using the unicode version of wx...
1. Instead of lib/gcc_dll/msw it is lib/gcc_dll/mswu
2. libwxmsw26.a and libwxmsw26_stc.a are also with the "u". (this coudl be changed by using WX_VER again)

[tiwag]

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.

at least a "per project" setting is absolutely necessary before i can use this feature.
i don't want to edit everytime the globals when i have to compile one project with wx24 and the other with wx26,
another one with wx-dll and another another one with wx-static-lib ...
not already mentioned debug and release versions ...
wx has soooooo much flavours...

--tiwag

[David Perfors]

An other thing.. when using your default paths, the compiler can't find wx/setup.h Originaly it could be find in $(WX_DIR)/lib/gcc_dll$(WX_CFG)/msw/wx/setup.h but the compiler can't find it.
WX_CFG is empty, so I think there is the problem... (I am not sure..) When I copy setup.h the the include/wx dir it works fine, but that is not an option for me, because I want to have more version of wx (one with directx support for instance)
Any suggestions?
btw, what when you don't use gcc for compiling wx? than the directory gcc_dll doesn't excist, does it?

[mandrav]

at least a "per project" setting is absolutely necessary before i can use this feature.

I 'm currently working on it. I will commit it later, when it's done.

An other thing.. when using your default paths, the compiler can't find wx/setup.h Originaly it could be find in $(WX_DIR)/lib/gcc_dll$(WX_CFG)/msw/wx/setup.h but the compiler can't find it.

Verify that $(WX_DIR)/lib/gcc_dll$(WX_CFG)/msw is in the include dirs for the project.

WX_CFG is empty, so I think there is the problem... (I am not sure..) When I copy setup.h the the include/wx dir it works fine, but that is not an option for me, because I want to have more version of wx (one with directx support for instance)
Any suggestions?

WX_CFG should not be empty only if you 've used CFG when building wxWidgets.
I use CFG=NonUnicode (for now) and so I set WX_CFG=NonUnicode. For empty CFG, WX_CFG should be empty too.
That's why I added WX_CFG: to allow for using different wx builds...

btw, what when you don't use gcc for compiling wx? than the directory gcc_dll doesn't excist, does it?

Currently, C::B only builds with gcc. When it can be built with other compilers we 'll probably add another variable, like WX_COMPILER or something, to control the "gcc" part of the paths

Yiannis.

[David Perfors]

I compiled wxwidgets without that CFG option, so I should left the WX_CFG empty, but that didn't work.. Now I have compiled wx with CFG and I set WX_CFG and it works like a charme. So I think there is a problem

[mandrav]

I compiled wxwidgets without that CFG option, so I should left the WX_CFG empty, but that didn't work.. Now I have compiled wx with CFG and I set WX_CFG and it works like a charme. So I think there is a problem

Strange because in wx docs it states that whatever you set as CFG is just appended to the output dir (gcc_dll in this case)...

I 'll look into it. Thanks

Yiannis.

[David Perfors]

Yiannis, did you moved the *.a files to $(WX_DIR)/lib/gcc_dll$(WX_CFG)/msw? because by default they are in $(WX_DIR)/lib/gcc_dll$(WX_CFG)..
When linking the sdk the linker says it can't find -lwxmsw26_stc and the only dir in the linker directories is: $(WX_DIR)/lib/gcc_dll$(WX_CFG)/msw
(hope you understand )

[mandrav]

Yiannis, did you moved the *.a files to $(WX_DIR)/lib/gcc_dll$(WX_CFG)/msw? because by default they are in $(WX_DIR)/lib/gcc_dll$(WX_CFG)..
When linking the sdk the linker says it can't find -lwxmsw26_stc and the only dir in the linker directories is: $(WX_DIR)/lib/gcc_dll$(WX_CFG)/msw
(hope you understand )

No, I didn't move the files. Have I made such a mistake? I 'll check it in a while.
On the WX_CFG issue: you did set it to be empty, didn't you?

Yiannis.

[David Perfors]

That wasn't possible, when you set a var empty, it is gone...

[mandrav]

That wasn't possible, when you set a var empty, it is gone...

You 're right. That's why it was not working...

Yiannis.

[David Perfors]

It is working now, thanks