Is wxWidgets compiled in debug mode by buildbot on purpose?

#1

Hello Robin,

Passing an invalid index such as wx.NOT_FOUND to GetString in wx.Choice results in the following error on MAC when using the latest build from the buildbot at http://buildbot.wxpython.org/

C++ assertion ""IsValid(n)"" failed at /Users/robind/projects/bb2/dist-osx-py38/build/ext/wxWidgets/src/osx/choice_osx.cpp(210) in GetString(): wxChoice::GetString(): invalid index.

But according to the documentation at https://docs.wxwidgets.org/trunk/group__group__funcmacro__debug.html#ga4822a2ea9fdd0bc98caa3ff42587743e it should return the empty string without any warnings.

The offending line is wxCHECK_MSG( IsValid(n), wxEmptyString, wxT("wxChoice::GetString(): invalid index") ); and according to the documentation of the macro at https://docs.wxwidgets.org/trunk/group__group__funcmacro__debug.html#ga4822a2ea9fdd0bc98caa3ff42587743e

the macro would provide the expected behavior if wxWidgets is compiled in release mode, but not if it is compiled in debug mode.

So my question, is the buildbot compling wxWidgets in debug mode on purpose? If so, that is fine, I just wanted to make sure. I am also not sure that using the macro is the recommend way of implementing the intended behavior so I am also referencing the issue at https://trac.wxwidgets.org/ticket/18852

#2

They addressed the problem with wx.Choice in wxWidgets https://github.com/wxWidgets/wxWidgets/pull/1995/commits/43dc1cefa44492acb2de27f72a3adc54aa540470 so compiling in debug mode should work and not throw, but I am still not sure if compiling in debug mode is done by design or accidentally.

#3

Yes, it is intentional. Actually it’s more of a hybrid compilation mode. By default, optimizations are turned on, as well as the flags that will activate the runtime assertions and other runtime checks. Other debug-only flags are not used. It’s done this way because otherwise Python developers would not receive any other indication of what they did wrong[1] , and many of those situations will result in a hard crash in the C++ code if the runtime checks are simply skipped over.

C++ developers will typically have both debug and release mode libraries they can work with, so seeing the assertions and other checks while in development mode and fixing the related issues is the natural order of things, and then they will likely switch to release builds without those runtime checks before deployment. For Python developers it’s a bit different. Except in special cases what they develop with is what they deploy with.

[1] Unless they do their own debug-builds, of course, but many Python developers are not able to do that.