Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: stahta01 on October 07, 2013, 08:37:24 pm

Title: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 07, 2013, 08:37:24 pm
I have a question about wxWidgets 3.0 and Code::Blocks files.

Are we going to create CodeBlocks_wx30.cbp CB project; when wxWidgets 3.0 are released?

Are we going to remove the *_wx29.cbp project files or rename them to *_wx30.cbp at that time?

I am currently using modified *_wx29.cbp project files to build against wxWidgets 3.0 in wxWidgets trunk.

Do you want the patches to change the *_wx29.cbp project files or instead ones adding *_wx30.cbp project files?

Tim S.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: oBFusCATed on October 07, 2013, 09:26:28 pm
I'd vote for patches to modify the wx29 files. There is no need to clutter the tree with another set of files.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: ouch on October 07, 2013, 10:13:30 pm
Agreed, 2.9 was never an official version anyway.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: Jenna on October 07, 2013, 10:23:52 pm
On windows we already need to set the global wx-variable, why not use it to provide the version-number as well ?
We could provide two sets of project-files one for stable wx (or better for fully supported wx) and one for development wx (or if wx30 is official stable for not fully supported wx). We would need two wx-variables: e.g. wx and wx-dev or similar). At the moment we already have wx and wx29.

On linux it would make sense to have a similar  set of global variables, at the moment I use patched wx29 project-files to make use of my own build of wx-trunk.

With global variables there would be one place to change and not many project-files (with different custom variables, as we have now).
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 07, 2013, 10:57:33 pm
On windows we already need to set the global wx-variable, why not use it to provide the version-number as well ?
We could provide two sets of project-files one for stable wx (or better for fully supported wx) and one for development wx (or if wx30 is official stable for not fully supported wx). We would need two wx-variables: e.g. wx and wx-dev or similar). At the moment we already have wx and wx29.

On linux it would make sense to have a similar  set of global variables, at the moment I use patched wx29 project-files to make use of my own build of wx-trunk.

With global variables there would be one place to change and not many project-files (with different custom variables, as we have now).

This sounds like a good third choice to me. I have decided to create a patch that updates the wx29 project-files to use a Global Var called wx_dev.
I plan to do only the 32-bit windows wx29 project-files and the update29.bat files.

Tim S.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 08, 2013, 01:46:44 pm
Changed to 32-bit windows files with names like *_wx29.cbp
Old Value
New Value

WX29
WX_DEV

$(WX_VERSION)
$(#WX_DEV.VERSION)

$(WX_SUFFIX)
$(#WX_DEV.SUFFIX)

$(WX_CFG)
$(#WX_DEV.CFG)

Plan to remove these; currently only done in CodeBlocks_wx29.cbp
<Variable name="WX_CFG" value="" />
<Variable name="WX_SUFFIX" value="u" />
<Variable name="WX_VERSION" value="29" />

Will attach patch after testing.


Tim S.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: Jenna on October 08, 2013, 02:02:03 pm
<Variable name="WX_VERSION" value="29" />
Note:
there are one or two projectfiles, where it is called WX_VER instead of WX_VERSION (at least on linux).
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 08, 2013, 05:36:24 pm
<Variable name="WX_VERSION" value="29" />
Note:
there are one or two projectfiles, where it is called WX_VER instead of WX_VERSION (at least on linux).

Found this one during testing "Addr2LineUI wx2.9.x" still doing more testing.

Tim S.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 09, 2013, 04:02:57 am
Patch to add missing wxWidgets headers to sdk_common.h. Discovered as a side effect of building wxWidgets trunk using MinGW 4.8.1.

Edit: I had to undefine WX_PRECOMP and comment out including wx/wxprec.h to reduce the PCH size or prevent a bad header from erroring out cc1plus.exe under 4.8.1 and wxWidgets trunk.

They were defined as missing if both of these things held.
1. They were included in a "#ifndef CB_PRECOMP" block.
2. They were required to build the SDK or codeblocks.exe (src/src folder)

Tim S.

Edit: Removed outdated patch.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 09, 2013, 04:09:18 am
Attached 7Zipped patch to convert wx29 32-bit windows cbp files to allowing version/suffix/cfg set in global var wx_dev.

I still plan to do more testing; but, my computer is unstable and I am afraid the patch might be lost.

Tim S.

Edit: My method of generating the patch does NOT create patch code the FORTRAN Plug-in.
Edit: Removed outdated patches.

Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: gd_on on October 09, 2013, 09:11:01 am
Hi,
I have not still tried your patches, but yesterday I have been able to build a working CodeBlocks on Windows 7 with wxWidgets 3.0.0.rc1, C::B svn 9392, everything compiled with TDM 4.8.1 distribution (32 bits).
To compile wxWidgets 3.0.0 I have made it as with wxWidgets 2.8 :
Code
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-fno-keep-inline-dllexport" >log.txt 2>&1
In the wiki, it is said than for a wxWidgets 2.9 version it's better to add "USE_STC=0 USE_PROPGRID=1", but it's not the case for 3.0 version : if you do that, the dll is not built because some scintilla components are missing.
To build C::B, I have used simply the _wx29 workspace as it is. I have just indicated C:\wxWidgets-3.0.0 in the environment wx29 variable and made a small add in C:\wxWidgets-3.0.0\lib : I copied in C:\wxWidgets-3.0.0\lib\gcc_dll, libwxmsw30u.a and libwxmsw30u_gl.a to libwxmsw29u.a and libwxmsw29u_gl.a respectively (just because in _wx29.cbps wxmsw29u is explicitely used, but they are effectively a 3.0 version). Of course, this is just for a test and stahta01 patches are certainly better than this workaround. Nevertheless, it works.

But, two remaining problems :
as with wxWidgets 2.9.5, there is still a warning concerning assert usage and I experienced one time only a crash, both probably caused by FortranProject plugin (I say that because the warning appears only when  FortranProject plugin is activated, and when I had the crash, in the .RPT file the name of this plugin appeared, but indirectly: not the main cause). The author of this plugin knows already this problem for wxWidgets 2.9.5 !

So, continue the good work. It's on the right way.

gd_on


[attachment deleted by admin]
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: Jenna on October 09, 2013, 09:22:10 am
Indeed, the crash/assert (shown in your screenshot) is caused by the Fortran-pluin's symbolbrowser, if I remembmer correctly.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: gd_on on October 10, 2013, 04:04:53 pm
Hi,
I have tried statha01 patches.
It's OK, but it's necessary to define the sub-globals variables WX_DEV.VERSION and WX_DEV.SUFFIX.
You can define them on the right part of the Global Variable Editor by entering "version" and "30" then "suffix" and "u" (without the quotes). Like that it's OK.

The problem I have seen, is that in a first try, I had not set those variables (I thought that C::B will ask them when needed, as it did for WX_DEV the first time!). C::B began to compile and after a while stopped because it said that wx/setup.h cannot be found in Platform.h. That's quite normal, because the path to this file was not correctly set.
But :
1) First thing: I had no messages telling me that WX_DEV.VERSION and/or WX_DEV.SUFFIX was not defined. May be not really easy to do, because there is another variable WX_DEV.CFG in the patches, not defined too, but which is finally (and must be) empty. (as WX_CFG in the different *_wx29.cbp)
2) The second thing is more annoying: After stopping on the line in Platform.h, telling me that wx/setup.h was missing, C::B hanged : no mouse reactions, even closing C::B by clicking the cross on the top of C::B window does not work the first time. If I insist, Windows show me a message indicating that C::B does not respond anymore and propose to kill the process. May be a bug somewhere in C::B ?
I tried this with several configurations of C::B (compiled with tdm 4.7.1, tdm 4.8.1 with the corresponding wxWidgets 2.8.12 configuration). It hanged in each configuration I tried.

gd_on
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: MortenMacFly on October 12, 2013, 04:04:32 pm
Edit: I had to undefine WX_PRECOMP and comment out including wx/wxprec.h to reduce the PCH size or prevent a bad header from erroring out cc1plus.exe under 4.8.1 and wxWidgets trunk.
Ah, that's interesting it seems you are talking about the same bug I reported in the GCC 4.8.1 announcement topic. I'll try your changes...
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 12, 2013, 04:18:18 pm
Edit: I had to undefine WX_PRECOMP and comment out including wx/wxprec.h to reduce the PCH size or prevent a bad header from erroring out cc1plus.exe under 4.8.1 and wxWidgets trunk.
Ah, that's interesting it seems you are talking about the same bug I reported in the GCC 4.8.1 announcement topic. I'll try your changes...

I am thinking its multiple headers that are causing the problem instead of size right now; but, I can not make a small sample to confirm this.

Tim S.

 
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 12, 2013, 11:46:41 pm
Here's my current patch for TDM MinGW GCC 4.8.1 and wxWidgets trunk.
Note: This is a Test patch trying to narrow down the cause; not one to apply to CB trunk!

Edit: Removed outdated patch.


Edit: Note: The testing below is NOT doing linking against wxWidgets because building the wxLibs takes to long.
Retested using 4.8.1 Compiler; This exact problem does NOT seem to exist in wxWidgets 2.9.2 (edited wx/wxcrt.h) using TDM MinGW GCC.
Retested using 4.8.1 Compiler; This exact problem does NOT seem to exist in wxWidgets 2.9.3 (edited wx/wxcrt.h) using TDM MinGW GCC.

Tested using 4.8.1 Compiler; This exact problem does seem to exist in wxWidgets 2.9.4 using TDM MinGW GCC.

Testing wxWidgets trunk SVN 70020 to see if problem exists; Did NOT see problem.
Testing wxWidgets trunk SVN 71000 to see if problem exists; Did see the problem.
Testing wxWidgets trunk SVN 70500 to see if problem exists; Did NOT see problem.
Testing wxWidgets trunk SVN 70600 to see if problem exists; Did see the problem.
Testing wxWidgets trunk SVN 70550 to see if problem exists; Did see the problem.
Testing wxWidgets trunk SVN 70520 to see if problem exists; Did see the problem.
Re-Testing wxWidgets trunk SVN 70500 to see if problem exists; Did NOT see problem.
Testing wxWidgets trunk SVN 70503 to see if problem exists; Did NOT see problem.
Testing wxWidgets trunk SVN 70509 to see if problem exists; Did NOT see problem.
Testing wxWidgets trunk SVN 70511 to see if problem exists; Did NOT see problem.
Testing wxWidgets trunk SVN 70512 to see if problem exists; Did NOT see problem.
Testing wxWidgets trunk SVN 70513 to see if problem exists; Did NOT see problem.

Testing wxWidgets trunk SVN 70514 to see if problem exists; Did see the problem.

Likely cause is "include/wx/generic/choicdgg.h"

NOTE: I have given up on solving this problem needs someone better at C++ and the MinGW Compiler to locate the problem to an exact cause.

Cross posted some of this info to http://forums.wxwidgets.org/viewtopic.php?f=19&t=38116 (http://forums.wxwidgets.org/viewtopic.php?f=19&t=38116) because maybe it will get a better person to try to solve the issue.


Tim S.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: ollydbg on October 13, 2013, 05:21:20 am

I am thinking its multiple headers that are causing the problem instead of size right now; but, I can not make a small sample to confirm this.

Tim S.
Hi, Tim, what do you mean by this?
I see in your patch in the post: http://forums.codeblocks.org/index.php/topic,18412.msg126028.html#msg126028
You remove the include directive of "#include <wx/wxprec.h>", but CB_PRECOMP is still defined. It looks like the generated pch file can be smaller now because not all the header files in "wx/wxprec.h" was included in the pch now.

BTW: I'm not sure the PCH issue is related only GCC 4.8.x under Windows, or the whole GCC versions under Windows. Anyone has the result of GCC 4.6.x and 4.7.x?

For some reasons, I want to build C::B under different Compiler, but the current build method does not let me hold different build folders, all the build files are put under devel folder. Can we have a variable which can relocate the output folder? like #CB_DEVEL or #BUILD, then I can have multiply build folders co-exists for different compilers.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 13, 2013, 05:34:47 am

I am thinking its multiple headers that are causing the problem instead of size right now; but, I can not make a small sample to confirm this.

Tim S.
Hi, Tim, what do you mean by this?
I see in your patch in the post: http://forums.codeblocks.org/index.php/topic,18412.msg126028.html#msg126028
You remove the include directive of "#include <wx/wxprec.h>", but CB_PRECOMP is still defined. It looks like the generated pch file can be smaller now because not all the header files in "wx/wxprec.h" was included in the pch now.

My testing patch shows that when one of the 3 to 5 headers are un-commented along with #include "wx/msw/wrapcctl.h" that the PCH causes the crash in cc1plus.exe.

BTW: I'm not sure the PCH issue is related only GCC 4.8.x under Windows, or the whole GCC versions under Windows. Anyone has the result of GCC 4.6.x and 4.7.x?

I have built using 4.7.1 and the crash from the PCH does not happen; but, the PCH was smaller so it only rules out a header sequence caused issue NOT a PCH size caused issue.

For some reasons, I want to build C::B under different Compiler, but the current build method does not let me hold different build folders, all the build files are put under devel folder. Can we have a variable which can relocate the output folder? like #CB_DEVEL or #BUILD, then I can have multiply build folders co-exists for different compilers.

I think that would work better as a Compiler custom variable than a Global var; but, I have never tried either one for a output folder.
There is about 6 update29.bat files that would be a source of problems to fix.

Tim S.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 14, 2013, 02:19:41 pm
Patch needed to confirm the (cc1plus.exe has stopped working) Problem exists in TDM MinGW GCC 4.8.1 and wxWidgets 2.9.4.

I think the problem did NOT exist in wxWidgets 2.9.3.

Tim S.

Code
Index: src/sdk/wxscintilla/src/wxscintilla.cpp
===================================================================
--- src/sdk/wxscintilla/src/wxscintilla.cpp (revision 9398)
+++ src/sdk/wxscintilla/src/wxscintilla.cpp (working copy)
@@ -5293,7 +5293,7 @@
                         evt.GetWheelDelta(),
                         evt.GetLinesPerAction(),
 /* C::B begin */
-#if wxCHECK_VERSION(2,9,2)
+#if wxCHECK_VERSION(2,9,5)
                         evt.GetColumnsPerAction(),
 #else
                         1,
Index: src/sdk/wxscintilla/src/ScintillaWX.h
===================================================================
--- src/sdk/wxscintilla/src/ScintillaWX.h (revision 9398)
+++ src/sdk/wxscintilla/src/ScintillaWX.h (working copy)
@@ -169,7 +169,7 @@
     void DoMiddleButtonUp(SCI_NAMESPACE_PREFIX(Point) pt);
 /* C::B end */
 /* C::B begin */
-#if !wxCHECK_VERSION(2,9,2)
+#if !wxCHECK_VERSION(2,9,4)
     enum wxMouseWheelAxis
     {
         wxMOUSE_WHEEL_VERTICAL,
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 19, 2013, 11:34:42 pm
Patches I am using to test CB trunk and wx trunk compiling with TDM MinGW GCC 4.8.1.
I am moving these patches to this new thread http://forums.codeblocks.org/index.php/topic,18568.0.html (http://forums.codeblocks.org/index.php/topic,18568.0.html)

That thread is obsolete; the CB Team applied patches to remove PCH for the wxWidgets 3.x projects which worked around the MinGW GCC 4.8.1 PCH bug.

Tim S.
Title: Re: wxWidgets 3.0 and Code::Blocks files question?
Post by: stahta01 on October 29, 2013, 05:44:40 pm
Patch to SpellChecker_wx30.cbp many things are NOT done correctly in this CB Project file.

Delete patch that is out of date; since most of it has been applied to CB SVN trunk.

Tim S.