Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: gd_on on November 15, 2022, 05:49:49 pm

Title: About environment and global variables
Post by: gd_on on November 15, 2022, 05:49:49 pm
I have set global variables with members that I can use in C::B builds to try to avoid multiple workspaces depending on wxWidgets versions and OS number of bits.
I have already proposed a set of cbps to do this in https://forums.codeblocks.org/index.php/topic,25068.msg170998.html#msg170998, and updated them on my own PC but not published new versions.

For example I have a cb_build.osbits with the value 64 and a wxwidgets.wx_version with the value 32.
So when building the name of the devel, obj or output folders, I can use in my build devel$(#wxwidgets.wx_version)_$(#cb_build.osbits) to obtain automatically devel32_64, .obj32_64...
It works well, is adapted automatically if you change the wxwidgets version and/or the os bits, defined at the global level.
Nevetheless, it gives some long lines in .cbp files, not easy to read.
It is possible to define a local environment variable as WX_VER=$(#wxwidgets.wx_version)_$(#cb_build.osbits). So I can write more simply devel$(WX_VER) in my cbps.
But I need to build this local environment variable in each .cbp.
The result is always good, because variables are still defined at global level in C::B.

It could be nice if I could define my WX_VER at a global level, eventually in my wx_widgets global variable as a new member. I tried to add a new member wx_widgets.wx_ver with the value $(#wxwidgets.wx_version)_$(#cb_build.osbits), but it is not accepted by the global variable dialog.
Not very surprising, because this syntax need to access an other member in the same variable, and another variable, which also means an order in the dependencies.

So, is such variable composition is possible?