Author Topic: [Proposal] Move the custom variables WX_SUFFIX... to global variables  (Read 1397 times)

Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 1519
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: [Select]
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?
« Last Edit: January 31, 2017, 11:49:19 am by BlueHazzard »

Online stahta01

  • Lives here!
  • ****
  • Posts: 5943
    • My Best Post
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #1 on: January 30, 2017, 10:28:33 pm »
Another solution is to use wx-config under windows, instead.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline golgepapaz

  • Multiple posting newcomer
  • *
  • Posts: 44
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #2 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.


Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10273
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #3 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.
<debugger plugin maintainer>
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 1519
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #4 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 ;)

Online stahta01

  • Lives here!
  • ****
  • Posts: 5943
    • My Best Post
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #5 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.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 32 bit.
On Debian Testing, compiling CB Trunk against wxWidgets 3.0.2.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10273
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #6 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.
<debugger plugin maintainer>
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 1519
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #7 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...

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10273
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #8 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?
<debugger plugin maintainer>
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline BlueHazzard

  • Lives here!
  • ****
  • Posts: 1519
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #9 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...
« Last Edit: March 02, 2017, 11:30:40 am by BlueHazzard »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4969
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #10 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. :)



If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Online oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10273
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #11 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.
<debugger plugin maintainer>
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4969
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: [Proposal] Move the custom variables WX_SUFFIX... to global variables
« Reply #12 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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.