Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Vadim Zeitlin <vadim-dz6zkcJxDG0gsBAKwltoeQ <at> public.gmane.org>
Subject: [all] making assertions available in all builds
Newsgroups: gmane.comp.lib.wxwidgets.devel
Date: Friday 6th February 2009 12:02:42 UTC (over 8 years ago)
Hello,

 We had already mentioned in the past the plan to make the release build of
wxWidgets more useful for the application development (this was referred to
as "merging debug/release builds" in the past but this is not totally exact
so I prefer to use this longer description). And as we want to release
2.9.0 a.s.a.p. and as this change could result in a lot of changes in the
build system I think we need to do it before 2.9.0, i.e. right now so I'd
like to launch the discussion about what exactly we're trying to achieve.

 I think that first of all we all agree that assertions should be enabled
(by default) in all builds, debug or release. However I believe that

1a. It should still be possible to turn them off (in case you're building
    for a resource-constrained system, for example, and really don't want
    to have any debugging code in your binary)
1b. Some asserts can be expensive so should still be disabled for normal
    library use and be enabled only for "full debug" build

To achieve both of these points I suggest copying GTK+ --enable-debug
configure option which takes 3 arguments: "no", "minimum" and "yes". Except
that I'd like to call ours "no", "yes" and "full" so that --enable-debug
(the new default) would do the most reasonable thing while --disable-debug
would be used for (1a) and --enable-debug=full for (1b).

 For Windows builds not using configure we need to specify the debug level
in setup.h. I think the simplest and also most backwards-compatible way to
do it would be to define __WXDEBUG__ by default and define the (already
existing but not used currently) WXDEBUG to 2 for full debug build while
leaving it as 1 for the normal builds.

 Finally, we need a way to control the asserts generation during run-time.
It can already be done by overriding wxApp::OnAssertFailure() and doing
nothing in it but this doesn't work for asserts generated before/after
wxApp creation/destruction so I suggest just having some global function to
do it. I also believe that asserts should be enabled by default but maybe
we should avoid calling wxTrap() in case of recursive assertions (which,
unfortunately, happen quite often, for example whenever an assert fails in
any code called from EVT_PAINT handler). What do you think?


 Second question is what, if anything, should be done for NDEBUG. As a
reminder, this is a standard macro which is supposed to be defined by the
user before including assert.h (or cassert) standard header to disable
asserts. We don't want to use it for this -- that's the whole point of
these changes -- so I think we should just ignore it completely, i.e.
remove the test for NDEBUG in wx/debug.h. Any other/better ideas?


 Third, currently wxLogDebug/Trace() disappear if __WXDEBUG__ is not
defined. I think this is wrong as having them doesn't really cost anything
so I think we should make them available even in the optimized "no debug"
build. But should we enable the debug logging by default?


 Fourth question is about what to do for API/ABI incompatibility between
debug and release builds. If we really want to make both builds (meaning
"normal" and "full debug" ones, as the "no debug" build will omit stuff
existing in the others and so won't be ABI-compatible with them -- but it's
ok because it won't be used often), we need to switch to using non-debug
CRT in the Windows builds. And this is rather bad news as using the debug
MSVC CRT is invaluable during debugging. Moreover, with MSVC we practically
must use the same CRT in the application using wx and wx itself so if wx
doesn't use debug CRT and the application does use it, as is the default
for any new project created in the IDE, it's not going to work at all. So
unfortunately it seems like we'd still need to have 2 ABI-incompatible
builds under Windows, it's just that what MSVC calls "Debug" build will be
"full debug" while "Release" build will be our "debug" one.

 Under Unix however there is only one CRT and so it should be possible to
use either debug or full debug wx shared library in the application without
rebuilding it. But for this to work they must have the same names which is
not the case now because of the "d" suffix. So should we get rid of this
suffix? And if so, what about Windows? The suffix does make sense there as
the libraries won't be ABI-compatible anyhow and it would be confusing to
have 2 different DLLs with the same name.

 So finally I think we shouldn't do anything about this, in particular not
even care about ABI compatibility between the different builds as it's
useless anyhow. Does anybody think otherwise?


 Fifth and finally, what about debug info/optimizations? Here I believe
that debug information should be always generated (except if explicitly
disabled with --disable-debug_info). As for optimizations, the normal
"debug" build should be optimized while the full debug one should not but
in either case --enable-debug just defines the defaults and an explicit
--{en,dis}able-optimise could still be used to override this.


 Please let me know what do you think about the choices above and whether
you see any other debug/release build differences which I forgot to
mention.

 Thanks in advance,
VZ
 
CD: 3ms