C::B and wxWidgets 2.9.5 under Windows

[gd_on]

I have seen that recently a few updates have been made in svn to support wxWidgets 2.9.5.
Nevertheless, when I try to build C::B svn 9271, on Windows, with wxWidgets 2.9.5, I obtain a non stable version (using CodeBlocks_wx29.workspace).
I have generated the monolithic wxwidgets lib as told in  http://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_2.9.0_to_develop_Code::Blocks_%28MSW%29
and updated also the setup.h which is in my C:\wxWidgets-2.9.5\lib\gcc_dll\mswu\wx folder (not only the one in my C:\wxWidgets-2.9.5\include\wx\msw).
C::B compiles, executes also, but I obtain several warnings concerning "assert" and even a crash if for example :
I open a project, and want to have a look to the properties of a source file by a right clic on it's name in the management/project window.
May be my wxwidgets is not correctly generated ? Is the containt of the wiki is still correct (was written for 2.9.0 version) ?
My command line for generating wxwidgets 2.9.5 is :
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 USE_STC=0 USE_PROPGRID=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-fno-keep-inline-dllexport"

(it's the same line for 2.8.12 but without USE_STC=0 USE_PROPGRID=1 and no manual modifications in setup.h)

Thanks for your help.

Gd_on

[stahta01]

You likely did every thing right.

I get the same crash for properties in some of my wxWidgets 2.9.x testing.

I have not had time to find the cause of the crash.

Tim S.

[Jenna]

This crash should be fixed in trunk now (svn r8362).

[gd_on]

OK, thanks.
An other small bug with wxWidgets 2.9.5 : see the attached file.

gd_on


[attachment deleted by admin]

[Jenna]

Looks okay for me on linux.
I will test it on windows this evening.

[mojca]

Since the thread is about wxWidgets 2.9.5 support: may I please request looking into fixes for Mac as well (even if there is no Mac developer in the team as I was told recently)?

See:

• http://trac.macports.org/browser/trunk/dports/devel/codeblocks/files
• https://trac.macports.org/ticket/40390

or some patches/reports on the tracker.

wxWidgets 2.8 cannot be compiled on a recent Mac OS X (other than via wxGTK using X11), so it's particularly important to get the version 2.9 working for a smooth user experience.

[stahta01]

wxWidgets 2.8 cannot be compiled on a recent Mac OS X (other than via wxGTK using X11), so it's particularly important to get the version 2.9 working for a smooth user experience.

I suggest working on the Building/testing of CB and wxWidgets 2.9/3.0 under Mac OS X.

The CB Team will NOT even think of supporting wxWidgets 2.9 as the primary wxWidgets; so, 3.0 needs to be released.
And, people need to test CB using the yet to be released wxWidgets 3.0.

I foresee  wxWidgets being released in October or November of this year (only 1 to 2 months past last posted schedule).
[FYI: The wxWidgets trunk already is using version number 3.0; so, it likely less than two week before trial builds.]

Tim S.

[mojca]

Maybe I need to clarify. I successfully built Code::Blocks 12.11 on Mac OS X (10.7) against both wxGTK 2.8.12 and wxOSX 2.9.5. I had to add some patches, but the majority of these patches works with both wxWidgets 2.8 and 2.9/3.0. I would like to request from the Code::Blocks team to review those patches and to apply them to trunk, so that next version of Code::Blocks could be compiled out-of-the-box without additional patches. I assume that wxWidgets 3.0 might be released before the next version of Code::Blocks?

I created most patches myself and only later realized that some of those have already been applied to trunk.

The program now runs, but there are still some minor issues (some pop-up windows with warnings for example), some of which have probably already been fixed in trunk (like in r9362 as mentioned above).

I'm not requesting to make Code::Blocks work with wxWidgets 2.9 only, but to apply the patches that are needed to compile Code::Blocks with version 2.9/3.0.

These are the patches that I needed to compile Code::Blocks 12.11: http://trac.macports.org/browser/trunk/dports/devel/codeblocks/files and there are a bunch of bug reports/patches in the tracker. Some patches might need modifications, but such cases all include additional notes.

[stahta01]

Maybe I need to clarify. I successfully built Code::Blocks 12.11 on Mac OS X (10.7) against both wxGTK 2.8.12 and wxOSX 2.9.5. I had to add some patches, but the majority of these patches works with both wxWidgets 2.8 and 2.9/3.0. I would like to request from the Code::Blocks team to review those patches and to apply them to trunk, so that next version of Code::Blocks could be compiled out-of-the-box without additional patches. I assume that wxWidgets 3.0 might be released before the next version of Code::Blocks?

I created most patches myself and only later realized that some of those have already been applied to trunk.

The program now runs, but there are still some minor issues (some pop-up windows with warnings for example), some of which have probably already been fixed in trunk (like in r9362 as mentioned above).

I'm not requesting to make Code::Blocks work with wxWidgets 2.9 only, but to apply the patches that are needed to compile Code::Blocks with version 2.9/3.0.

These are the patches that I needed to compile Code::Blocks 12.11: http://trac.macports.org/browser/trunk/dports/devel/codeblocks/files and there are a bunch of bug reports/patches in the tracker. Some patches might need modifications, but such cases all include additional notes.

So, your patches are NOT against either wxWidgets trunk or CB trunk; I know I do NOT have the time to fix the patches.

Tim S.

[mojca]

So, your patches are NOT against either wxWidgets trunk or CB trunk; I know I do NOT have the time to fix the patches.

These patches are not for wxWidgets themselves, they are all for CB. Yes, the patches on the link are meant to be applied against 12.11, but those that haven't been applied already mostly apply without a problem and I have no problem doing minor modifications to them so that they could go straight to trunk (as long as someone plans to commit the changes soon rather than waiting until the patch would become incompatible with trunk again).

I have no problem migrating patches to the trunk, but I need to point out that I'm unable to compile the complete CB from trunk (http://developer.berlios.de/bugs/?func=detailbug&bug_id=19114&group_id=5358) which is why I kept patching the released version first.

What exactly should I do to get the patches applied? Just as an example, here's a report where I can still submit a patch (adding a single include), but it's not likely that doing it would mean any less work anyone involved:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=19113&group_id=5358

I would be grateful if someone would at least replied to the tickets with at least some kind of comment like "this looks ok to me, please create a patch against trunk and I will commit it" or "this doesn't look acceptable to me for this or that reason, we need to find another way to solve the problem", just to make sure that it won't be just hours of extra work for me without any developer actually looking into it later.

Please advise.

[oBFusCATed]

Just create patches against trunk and we can talk:)
Patches against 12.11 are useless.

[mojca]

I submitted a revised patch for wxWidgets 2.9 compatibility to

https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=3499&group_id=5358

As well as a few others:

• http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=3496&group_id=5358
• http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=3502&group_id=5358
• http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=3503&group_id=5358

There are a few remaining problems, but I'm not yet sure how to (properly) fix those.

[stahta01]

• http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=3503&group_id=5358

The changes to scintilla code will likely need submitted upstream to them for the changes to be put into CB.
IIRC, Morton updates the scintilla code from time to time from the upstream.

Edit3: I noticed these in the scintilla code section; so if doing non upstream changes it might help you get the patch applied.

Code

/* C::B begin */
/* C::B end */

I also suggest looking at the Category options when submitting patches.
If you think some are really bugs; please submit a bug report on them linking to the patch.

NOTE: I am NOT a CB dev; so, all I am saying are suggestions; not required. I gave up doing patches and stuff due to the work it took to keep them updated for CB trunk. But, yours are shorter; maybe my problem was patching to much in a single patch.

Tim S.

[oBFusCATed]

I gave up doing patches and stuff due to the work it took to keep them updated for CB trunk.

What should this mean? We haven't apply some of your patches?

[stahta01]

I gave up doing patches and stuff due to the work it took to keep them updated for CB trunk.

What should this mean? We haven't apply some of your patches?

I had patches that took many months to be applied; to keep updating them to trunk took a long time.

Then, I had to add all the unnecessary ifdefs because of the lack of documentation in wxWidgets of wxstr function.
I felt like it was a waste of my time to submit patches after awhile.
I believe my SDL patch for the wizard has still NOT been applied; but, I gave up on it long ago.

Tim S.