Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: BlueHazzard on January 30, 2017, 08:42:51 pm

Title: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: BlueHazzard on January 30, 2017, 08:42:51 pm
Hi,
from time to time i try new wxWidgets builds with codeblocks (debug, non debug, wx3.1, trunk ecc...)
On Windows you have always to adjust the "Custom variables"
Code
WX_SUFFIX
WX_CFG
WX_VERSION
for every project in the workspace. I know i can use a plugin for this, but this will alter the project files and so they are no longer in sync with the repository and show differences. I think the global variables would be a better place for this type of setting. Also if i alter the configuration of the codeblocks.cbp i can not use the same plugins, so the main project and the plugin projects are connected, and i think it makes sense to configure them from one central place...

So a possibility would be to use the custom fields of the $(#CB_RELEASE_TYPE) variable. Something like $(#CB_RELEASE_TYPE.WX_CFG) ecc.
A better place would be the $(#WX) variable....

any thoughts about this?
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: stahta01 on January 30, 2017, 10:28:33 pm
Another solution is to use wx-config under windows, instead.

Tim S.
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: golgepapaz on January 31, 2017, 07:51:06 am
Hi,
from time to time i try new wxWidgets builds with codeblocks (debug, non debug, wx3.1, trunk ecc...)
....
So a possibility would be to use the custom fields of the $(#CB_RELEASE_TYPE) variable. Something like $(#CB_RELEASE_TYPE.WX_CFG) ecc.
A better place would be the $(#WX) variable....

I second that. Recently I needed to use wx3.1 on msys2 since the earlier wxWidgets does not build with gcc6.3
I give up converting at third plugin project or so. we have wx30, wx30_64,wx30-unix etc and their associated update and batch build scripts.
Adding a new configuration feels like major PITA.

Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: oBFusCATed on January 31, 2017, 08:36:23 am
any thoughts about this?
Global variables don't have default values - so it will be hard to setup if you don't know what you're doing.
I'm doing this by having a patch that changes the versions and just rebase it on top of everything.
Btw switching to wx-config doesn't help because not everybody is installing wx-config in the global place for it.
So again users will have to change `wx-config --libs` with `<path>/wx-config --libs` in every project.
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: BlueHazzard on February 01, 2017, 01:24:48 am
Well, you have to set $(#WX) anyway, so i don't think this should be a issue if it is mentioned in the build instruction or readme file.

Or we implement default values for global variables ;)
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: stahta01 on February 01, 2017, 01:40:22 am
Well, you have to set $(#WX) anyway, so i don't think this should be a issue if it is mentioned in the build instruction or readme file.

Or we implement default values for global variables ;)

I think default values for global variables or a script that sets up default values for global variables is a good idea.
Anyone know if the scripting language can setup default values for global variables?

Tim S.
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: oBFusCATed on February 01, 2017, 08:28:59 am
Well, you have to set $(#WX) anyway, so i don't think this should be a issue if it is mentioned in the build instruction or readme file.
No one reads instructions. Everybody tries if it works and then asks in the forum.
Also the UI doesn't tell you which sub-variables you need to fill in.

Or we implement default values for global variables ;)
This is the only option if you want to use those...

But I'm not sure our current way of managing projects is good idea. Probably it is better to switch to something like cmake which can generate C::B projects and can handle the differences between platforms and wx versions.
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: BlueHazzard on March 01, 2017, 09:54:22 pm
But I'm not sure our current way of managing projects is good idea. Probably it is better to switch to something like cmake which can generate C::B projects and can handle the differences between platforms and wx versions.
i don't like the idea to add a other build system to create a build system ;) (other then standard make)

Lets think about this:
A easy to implementable solution, would be to set the non existent global variables with some squirrel script.
1) Check if the variable is there with "UserVariableManager.Exists()"
2) If not set it to some default value

For this is needed:
1) Add function UserVariableManager::SetVariable(wxString name, wxString value) to the sdk code
2) Add UserVariableManager::SetVariable(wxString name, wxString value) to the squirrel binding
3) Have a possibility to run a script at project loading

Point 3 is the "most tricky" part, but it would be useful in other places to.... Beside point 3 this is a easy, non intrusive fast solution and point 3 has also his advantages.
I think this would also not be a problem to implement... One possibility is to add a new tab in the project properties with load script, or to add a script in the "Build script" tab
We can't use a build script (the most easy way) because codeblocks will complain about the missing variables on load time and not at build time...

Disclaimer: I am a fanboy of scriptable things/ programs, they make things a lot easier...
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: oBFusCATed on March 02, 2017, 12:37:54 am
i don't like the idea to add a other build system to create a build system ;) (other then standard make)
Have you used it? I was sceptical (quite a bit) that cmake is any good. It has problems, but as a tool used daily it has tons of advantages and makes things a lot easier in cross platform projects.

For this is needed:
1) Add function UserVariableManager::SetVariable(wxString name, wxString value) to the sdk code
2) Add UserVariableManager::SetVariable(wxString name, wxString value) to the squirrel binding
3) Have a possibility to run a script at project loading
I don't understand how this will help? How will it find where is wxwidgets located? What version is? What variant on windows?
Also I'm not sure this will be discoverable by non cb projects. How will we teach them to write their project loading script?
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: BlueHazzard on March 02, 2017, 11:25:46 am
Quote
I don't understand how this will help? How will it find where is wxwidgets located? What version is? What variant on windows?
Also I'm not sure this will be discoverable by non cb projects. How will we teach them to write their project loading script?
This is NOT what I want to achieve and not the current workflow on windows. I for example have 5 different wx version on my pc, so it would be impossible for any script (CMake or other) to guess the right installation. What i want is a EASY way to set the path to wxWidgets and its configuration for the whole codeblocks workspace and for noobs, an easy possibility to use the default installation way. Setting the path is implemented at the moment.
At the moment you have to set the path to wxWidgets and this is fine. The amount of reports with the problem to set the path is non existent in this forum, so it is no problem for other/new user. Also the default configuration seems to work fine, because also for this there are no complains.
The problem i want to address is that wx uses build configuration parameter in its name. This parameter to create the name are currently configured at a project level, but if you want to build codeblocks you want this parameter at a workspace level. Simply as that... No auto detection and no other complicated things... Autodetection is brain.exe who sets one path one time, all other things make it more complicated.

Quote
Have you used it? I was sceptical (quite a bit) that cmake is any good. It has problems, but as a tool used daily it has tons of advantages and makes things a lot easier in cross platform projects.
I have tried to compile KiCad many times on windows and linux and the auto detection of wx NEVER worked. I always had to tune paths, or even find missing cmake scripts, search through tons of configuration parameter to fiddle the right ones under the advanced option...

just my two cents...
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: ollydbg on March 02, 2017, 04:15:27 pm
After reading your discussion, I think having C::B IDE's global variables is good enough.
We have already cbp files for 2.8, 3.0 version of C::B under Windows, but I'm currently using wx 3.1, so I have to maintain a patch which should rebase every time when I have to synchronized with the official svn/git.

For wx library, I think $(#WX)  is enough, and we can have all the sub fields like WX.VERSION or similar things.
For cb, we should have CB.RELEASE_TYPE or other fields under CB.

That way, we can have only one cbp files. :)



Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: oBFusCATed on March 02, 2017, 09:02:28 pm
That way, we can have only one cbp files. :)
We cannot, because the set of files differs between wx2.8 and wx3.0. We need a way to conditionally include files and if we implement this we'll get to the cmake level of complexity.
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: ollydbg on March 03, 2017, 08:50:26 am
That way, we can have only one cbp files. :)
We cannot, because the set of files differs between wx2.8 and wx3.0. We need a way to conditionally include files and if we implement this we'll get to the cmake level of complexity.
OK, so let's have two cpbs, one for wx2.8 and the other for wx3.0.
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: BlueHazzard on September 12, 2018, 07:53:37 pm
Ok, i would like to dig up this Topic again.

Here is a patch for the wx30 project files. With this patch it is easy to switch between wx versions and configurations...

Simply set the global variables for

Code
wx30.suffix = u
wx30.version = 30

and you have the old behavior. If you want to try wx31, simply set
Code
wx30.version = 31
and recompile. This will affect the whole codeblocks workspace.
want to debug things? Set
Code
wx30.suffix = ud
recompile and you have the right configuration for the whole workspace.

A other upside is that you do not change the project file, so you don't have any changes in the CVS if you want to use the debug configuration...

This is windows only!
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: oBFusCATed on September 12, 2018, 08:03:47 pm
What happens when these variables are empty?
How do you know what to put in there for initial values if you're new users and just starting?

Global variables are powerful, but quite confusing feature...
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: sodev on September 12, 2018, 08:18:06 pm
This question i also always ask myself when a fresh installation of CodeBlocks asks me to put something into cb_release_type :P.

Anyway i like having this in the global variables as well because CodeBlocks has so many project files, changing this is such a PITA. And no, i don't use that Project Options Plugin, it is not that intuitive to use plus in the dark days of the past some of these variables had a different name in a few projects.

But i might be a bit biased, i use a lot of these global variables to pull in external libraries into my projects without polluting the project files with machine dependent paths :).
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: oBFusCATed on September 12, 2018, 08:21:50 pm
In my opinion everybody doing something a bit more complex should reconsider if using something like cmake isn't a better option. C::B's build system can do a lot of things, but it is more limited compared to something like cmake...
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: BlueHazzard on September 12, 2018, 09:08:59 pm
What happens when these variables are empty?
How do you know what to put in there for initial values if you're new users and just starting?

We have discussed this countless times on the top. The conclusion was, that at the moment the same thing is to do for the "wx30" variable and the "cb_release_type"...
 We should provide a proper README and INSTALL file...
I volunteer for all upcoming forum posts to answer them without any grumble
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: oBFusCATed on September 13, 2018, 01:07:34 am
Hehe, and when you're tired of answering posts and quit?
Or people just don't be bothered to even post a question after they are greeted with some messages on project open?

I think it will be better if we have some UI and project storage for defaults and/or note/hints/help strings for the global variables?
I'm not really sure how this is supposed to work, but we need something like better than the current dialog.

A good example for similar tools is cmake-gui. It lists (almost) all variables and allows the user to set/change them.
There are tooltips with hints/help which is provided by users.
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: ollydbg on September 16, 2018, 12:58:22 am
BlueHazzard's work is great!

Under Windows, we have cbp/workspace/bat files for wx3.0 and wx3.1 and also we have 32bit and 64bit, maybe soon we will have wx3.2. I think we should only have one kinds of such files.

About OBF's suggestion of the UI, yes, it should be improved, at least some hint strings in the C::B's global variable setting dialog.
Title: Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
Post by: AndrewCot on August 24, 2021, 05:43:47 am
I second that BlueHazzard's work is great!

This saved me a number of hours trying to see what the best option was to support building against various wxWidget combinations (3.1.5 V's trunk <aka 3.1.6 in the future> and/or  debug V's release) without modifying the Windows project files every time I wanted to change a wxwidget variables.