On reading the code more carefully (it is pretty convoluted in app.h) I suspect that I may have been mistaken about NDEBUG. But defining wxDEBUG_LEVEL=0 does also work, and I feel that the reasons for excluding asserts in release builds are still valid.
Cheers, --Charlie > As far as I can tell from studying the code, the documentation is wrong about > this. I believe that all references to NDEBUG in the code or its derivatives > are commented out. > > The reason for excluding wxWidgets asserts in release builds is that they > create a crash on most platforms when the application is not run under a > debugger, which cuts short our alpha testers work with them. And we have > found that the vast majority of wxWidgets asserts are merely warnings about > harmless inconsistencies. > > That said, I do run the debug version under the debugger before building the > release version, and strive to eliminate the asserts to the extent I find > them. > > Cheers, > --Charlie > > On Mar 3, 2014, at 11:53 AM, Juha wrote: > >> On 27 February 2014 05:10, Charlie Fenton <[email protected]> wrote: >> Hi Toralf, >> >> I believe you need to pass the --disable-debug_flag argument to configure >> when building wxWidgets 3.0 to disable these asserts. Unfortunatley, >> wxWidgets 3.0 has wxDEBUG_LEVEL set to 1 by default for both debug and >> release builds, which enables all asserts and most other debugging features. >> wxWidgets 2.8 disabled these features by default on release builds. >> >> Reading the docs[1,2], your previous email and the relevant parts of the >> headers[3-5], it looks like you only need to define NDEBUG when compiling >> Manager. This leaves the assert code in place but disables it. No need to >> build a special version of wxWidgets. >> >> But I have to ask. You have just done rather large changes to Manager, began >> using a (sort of) brand new version of a framework and I understand you are >> planning something big with notices. With all these changes you have likely >> introduced a few bugs too. (Well this conversation started as bug report.) >> >> So, why wouldn't you want to have asserts enabled? I mean, we are alpha >> testing BOINC here and what better way is there to get bug reports than to >> pop an error message right in front of the tester? >> >> Disabling asserts just hides those bugs. I don't understand how that would >> help. >> >> Just in case you were curious why the asserts are included in release build >> of the library here's a blog post that explains it: >> >> http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html >> >> FWIW. GLib (and GTK+ and pretty much everything Gnome) takes middle ground >> between no checks and fatal asserts. If an application hits a logic error a >> message like this is printed to stderr: >> >> (cinnamon:2069): Clutter-CRITICAL **: clutter_actor_queue_relayout: >> assertion `CLUTTER_IS_ACTOR (self)' failed >> >> The application then continues to limp along or crashes right on the spot. >> You could set up Manager to do something similar. >> >> >> [1] http://docs.wxwidgets.org/3.0/overview_debugging.html >> [2] http://docs.wxwidgets.org/3.0/group__group__funcmacro__debug.html >> [3] >> http://trac.wxwidgets.org/browser/wxWidgets/tags/WX_3_0_0/include/wx/app.h >> [4] >> http://trac.wxwidgets.org/browser/wxWidgets/tags/WX_3_0_0/include/wx/debug.h >> [5] >> http://trac.wxwidgets.org/browser/wxWidgets/tags/WX_3_0_0/include/wx/log.h >> >> -Juha > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
