Menu
▾
▴
#1300 difference in behavior between local and global variables
There is a difference of behavior between local and global variables which is annoying, but apparently does not cause too many problems, at least on Windows.
I see this in cbp files.
If in CodeBlocks_wx32_64.cbp for example, we have:
<environment>
<variable name="WX_CFG" value="">
...</variable></environment>
When used in
<Add directory="$(#WX32_64.lib)/gcc_dll$(WX_CFG)" />
It is expanded as C:\wxWidgets-3.2.0\lib\gcc_dll as shown in build logs.
But if you set this variable as a global one, for example in WXWIDGETS.WX_CFG
- you can try to set it as an empty value, but C::B suppress it silently (or does not retain it as valid ?)
-
and if you set it to an empty string as "", it works, but when used in
<add directory="$(#WXWIDGETS.lib)/gcc_dll$(#WXWIDGETS.WX_CFG)">
It is expanded as C:\wxWidgets-3.2.0\lib\gcc_dll"" as seen in build logs.</add>Under Windows, it is still correctly interpreted, but annoying.
What does this mean? By 'suppress it' you mean it is replaced by '(invalid)' or you are asked to set it, or it is not saved on exit?
Out of curiosity can you try my patch here and look if it is fixed?
forum
I mean that if I create the wx_cfg field in the cb_build global variable, but put nothing as value (keep the field empty), then close the global variable dialog and reopen it, the wx_cfg field has disapeared. But, if I put "" as value, it still here when I reopen the dialog. The problem is that those two characters "" are used to build the path name as show above.
In the main part of the dialog, If I put nothing as value, I obtain a message telling me that it's not valid and after reopen, it's effectively marked (invalid) in the value field.
I'll try your forum patch tomorrow.
See [1188] for a patch to solve the issue.
Please consider reading the idea behind global compiler variables (GCV) here:
https://www.codeblocks.org/docs/main_codeblocks_en3.html#x3-1220003.7
Its meant to be a per-machine setting that does not change.
So GCVs are not intended to be changed extensive on a machine but more to roll-out a configuration to computers that functions as a fundamental setup.
Therefore, an empty GCV makes actually no sense. For this purpose environment variables are the way to go. So the warning comes because of a mis-use of GCVs. If you allow non-empty GCVs you screw the concept and cannot even warn the user!
I understand the concept. But in all cbp, we have a local variable defined by "WX_CFG" value="". I'm just trying to do the same thing with GCV. So if I put there "" it seem to work except that this double quote is integrated in the name. May be you can detect this "" string and have a specific treatment. I have still not used the patch in ticket 1188, but it may do the job.
To bluehazzard :
I tried the patch published on the forum. I does not solve this double quote problem apparently.
Patch V2 in ticket 1188 solves the double quote problem. I have not seen side effects.
Thanks Andrew.
What if you define a member so for example wx.config and let that empty. Wouldn't this be more in line with the way how variables are meant to be used?
Thank you for testing!
I think I have already answered this question, but may be not clearly. In my case I create a main variable, cb_build for example (but it's the same thing for any main variable), then I create a member wx_cfg on the right part. If I let the value part empty, close the dialog and reopen it, this member has been silently deleted (not marked invalid as it is for the main variable). But if I set it to "", it works, and with Andrew patch [1188] it's OK.
OK, but defining in each cbp exactly the same set of 3 environment variable is also a programming non sense. May be it could be a way to define this set of variable at an intermediate level, at the workspace level for example (presently not possible)
Well I guess your are missing something here: Are you aware that an environment variable (env var) could also come from the shell/system?
So you can do these steps to basically just use the envvar instead of defining it over and over again in CBP files:
1.) Set it up within the scope of C::B using the "envvar" plugin
2.) Set it up at project scope / target scope using the envvar plugin
3.) Set it up in the shell before you start C::B
4.) Set it up in your OS settings for the user only
5.) Set it up in the OS for the whole system (=all users)
...so it is easily possible at at the workspace level and it always was.
Once again: Envvars are very powerful and GCVs are for the proposed issues that an envvar cannot solve. And by design they behave different when it comes to empty values as an envvar.
OK. I'm waiting for devs proposals to avoid these multiple definition in Cbp and those multiple workspaces/cbps versions depending on wxWidgets versions in 32/64 bits...
If you are annoyed with that, simply remove the definition of the envvars per CBP; keep just their usage; convert the global var to an envvar; setup envvars on your system as desired and run C::B compilation. But what are you actually trying to "fix"? Usually you build exactly one flavour - the one you are most comfortable with...?!
Sorry, I don't understand. Avoiding these local variables and trying to have workspaces and cbp as independent as possible of the wxwidgets versions and number of bits is the goal of my proposals in https://forums.codeblocks.org/index.php/topic,25068.msg170998.html#msg170998.
It's not perfect, I know. May be still too complicated for "standard" C::B users, or subjects to errors if not well configured.
It's because I have made this work that I have found there was a small problem with double quotes in GCV but not with local environment variables. It can be solved with a patch in ticket 1188. But if you think it's not acceptable ... why not. But seeing that there are now so many versions to build C::B (30, 31, 32, 31_64... ) need some work to try to unify this. It's probably difficult to unify also windows, linux and MacOS cbps and workspaces, but it could be fine.
It will get worse when 3.2 make it to Linux as another set of project files will be created if the current process is still used. Then another two sets will be needed when Mac workspace/project files eventually land at some stage in the future id the current process is still used.
So eventually going down the current path would mean that to make a change a dev would need to update all of the following sets at some stage in the future if my crystal ball is working correctly:
* Windows wx3.1 32 bit
* Windows wx3.1 64 bit
* Windows wx3.2 32 bit
* Windows wx3.2 64 bit
* Linux wx3.0
* Linux wx3.2
* Mac wx3.0
* Mac wx3.2
This is a big list.......