ALL: review of debug patch wanted
Vadim Zeitlin
I've implemented the changes to debug facilities in wx discussed (well,
mostly monologued about by me) before and would like to request comments
about the patch at http://trac.wxwidgets.org/ticket/11175
For those who didn't follow the previous discussions, let me briefly
(re)describe the changes:
The main one is that there are no debug and release builds of wx itself
any more. All builds include assertions by default and the only distinction
between them is under Windows where debug build uses debug CRT libraries
while the release one uses, well, release ones. MSVC builds now also always
generate debug info by default (even in release builds as this is needed to
have stack traces in the asserts and to make sense of mini dumps generated
by wxDebugReport).
We still keep BUILD variable (which is "debug" or "release") under Windows
but it doesn't affect DEBUG_FLAG any longer and in fact still exists solely
for compatibility with user scripts which may use "make BUILD=release".
The DEBUG_FLAG option itself can still be set separately to 0 or 1 to
disable or (explicitly and redundantly) enable wxDEBUG_LEVEL as well as
DEBUG_INFO one which doesn't change. And the libraries still have "d"
suffix in debug builds indicating that they're linked with debug CRT and so
may be only used by the programs which are themselves linked to them, i.e.
built in debug mode.
Under Unix configure arguments now work as following (this strives to
remain compatible with previous versions as much as possible while still
making sense):
- If --enable-debug is given, the library is compiled in approximation of
the old "debug" build, i.e. optimizations are disabled and debug
information is generated.
- If --disable-debug is given, wxDEBUG_LEVEL is set to 0 disabling all the
assertions completely and debug information is not generated.
- If neither is given, the library is compiled with wxDEBUG_LEVEL set to 1
and optimizations enabled (although this can be overridden by an explicit
--disable-optimise, of course). I did not enable debug information for
this (default) build for now because it makes the libraries much huger
and we should probably investigate the possibility to extract debug info
in separate files if we want to do this.
- The debug_xxx options also still exist: --disable-debug_flag behaves
mostly as before, i.e. sets wxDEBUG_LEVEL to 0. And --enable-debug_info
can be used to turn on debug information generation without changing
anything else.
Notice that debug suffix ("d") is not used at all under Unix any more.
For the user programs, there is still a difference between debug and
release: in the latter, assertions and debug output are disabled by default
(but may both be reenabled). In addition, the user code can be compiled
with wxDEBUG_LEVEL set to 0 which would disable any asserts from being
compiled in at all in the user code.
The obvious advantage of these changes is that we can now provide a single
binary version of the library suitable both for development and production
use, so there should be no need for different debug and release packages
any more. The obvious drawback is that the release build is now marginally
slower (not measured, but the only place where I think this might be
measurable at all is in wxString) and slightly bigger: shared wxBase
library grew by 12% (from 2718744 to 3050621 bytes) and wxCore grew by
almost 8% (from 6642778 to 7161829) under Linux amd64. Under Win32 my own
biggish program (M.exe) grew by 7% after these changes.
I think the added convenience and simplicity are well worth this (and
people can still recompile everything with wxDEBUG_LEVEL == 0 if they
really want to). Please let me know if you disagree or if you see any other
problems with these changes.
Thanks in advance for any comments about the patch!
VZ
Julian Smart
Vadim Zeitlin wrote:
> Hello,
>
> I've implemented the changes to debug facilities in wx discussed (well,
> mostly monologued about by me) before and would like to request comments
> about the patch at http://trac.wxwidgets.org/ticket/11175
>
Thanks for this (though it scares me :-))
> Notice that debug suffix ("d") is not used at all under Unix any more.
>
It might be nice if we had a switch e.g. --lib-naming-compatibility that
would make the libraries named the same way as before, to make it easier
to migrate without changing loads of makefiles (and for tools that
haven't been updated to spit out the correct information yet). I know
you can use wx-config to get the names of most wxWidgets libraries but
not all libraries are supported, e.g. richtext, and makefiles have to
make explicit references to the libraries.
>
> For the user programs, there is still a difference between debug and
> release: in the latter, assertions and debug output are disabled by default
> (but may both be reenabled). In addition, the user code can be compiled
> with wxDEBUG_LEVEL set to 0 which would disable any asserts from being
> compiled in at all in the user code.
>
I don't understand this part - how can wxDEBUG_LEVEL have different
values in the library and user code, and how is this specified? Before,
you used configure debug switches and knew that they applied equally to
both the library and the app. This difference between app and library
sounds potentially confusing.
>
> The obvious advantage of these changes is that we can now provide a single
> binary version of the library suitable both for development and production
> use, so there should be no need for different debug and release packages
> any more. The obvious drawback is that the release build is now marginally
> slower (not measured, but the only place where I think this might be
> measurable at all is in wxString) and slightly bigger: shared wxBase
> library grew by 12% (from 2718744 to 3050621 bytes) and wxCore grew by
> almost 8% (from 6642778 to 7161829) under Linux amd64. Under Win32 my own
> biggish program (M.exe) grew by 7% after these changes.
>
> I think the added convenience and simplicity are well worth this (and
> people can still recompile everything with wxDEBUG_LEVEL == 0 if they
> really want to). Please let me know if you disagree or if you see any other
> problems with these changes.
>
Personally I (as a wxWidgets user) don't gain any advantages at all from
these changes, because I always compile wxWidgets locally from source
and am quite happy to have debug and release builds. I also really don't
want wxWidgets assertions popping up in release builds and would be
supprised if anyone else does (yes, I know, with sufficient testing this
would never happen, but in reality some get through). So unfortunately I
get the disadvantages of slower and larger code, and changing my build
system, without any benefits. Actually, I guess I don't have to get any
disadvantages so long as I build wxWidgets in a non-standard way and
change all my makefiles and tools :-) I don't know how many people
actually use the wxWidgets libs built into the distribution - I need to
be able to tweak my version, so build from source, and would expect most
serious developers to need to do the same. OTOH at least for getting
started, the release/debug lib confusion may be a significant factor, I
have no idea. But maybe that's as nothing compared with trying to
understand the new debug permutations.
Hang on a sec, debug information is not even available in the default
library configuration. Surely any serious programmer is going to want
debug information, so we're back to square one with the developer pretty
much always having to build a debug version, aren't we? Blimey, this is
going to get confusing. I wonder if the extra complexity and required
mental models are going to be worth the benefits of having assertions in
the release library? (Which to me personally is a disadvantage anyway.)
I really don't want to be negative after all the work you've put into
this - I would like to like it - but on balance this seems confusing,
less-efficient-by-default and with rather minor benefits.
Regards,
Julian
Alec Ross
>I don't understand this part - how can wxDEBUG_LEVEL have different
>values in the library and user code, and how is this specified? Before,
>you used configure debug switches and knew that they applied equally to
>both the library and the app. This difference between app and library
>sounds potentially confusing.
And a risk of ODR violations?
--
Alec Ross
Vadim Zeitlin
JS> > Notice that debug suffix ("d") is not used at all under Unix any more.
JS> >
JS> It might be nice if we had a switch e.g. --lib-naming-compatibility that
JS> would make the libraries named the same way as before,
I think it would only increase the confusion and not really help. Indeed,
if someone gets an error because they hardcoded the library name with "d"
in their script/makefile, is it really simpler for them to recompile the
library with --lib-naming-compatibility or just change their script? I am
pretty sure it's the latter. The main problem is understanding what you
need to do but adding this switch won't help with it.
JS> I know you can use wx-config to get the names of most wxWidgets
JS> libraries but not all libraries are supported, e.g. richtext, and
JS> makefiles have to make explicit references to the libraries.
Why wouldn't richtext be supported by wx-config? It seems to work fine
here.
Also, while I agree that in practice some people still don't use wx-config
I really can't summon much sympathy for them. wx-config is the only
officially supported way to get wx build options since many, many years.
JS> > For the user programs, there is still a difference between debug and
JS> > release: in the latter, assertions and debug output are disabled by default
JS> > (but may both be reenabled). In addition, the user code can be compiled
JS> > with wxDEBUG_LEVEL set to 0 which would disable any asserts from being
JS> > compiled in at all in the user code.
JS> >
JS> I don't understand this part - how can wxDEBUG_LEVEL have different
JS> values in the library and user code,
There is no problem with having a different value for a macro (to reply to
Alec, unlike functions and classes they're not subject to ODR) when
building the library and the user code. We already do it all the time with
WXBUILDING (defined when building the library but not when building the
user code) and WX{MAKING,USING}DLL. The same thing can be done here except
that it's optional: by default wxDEBUG_LEVEL is 1 but you may change this
by predefining it to something else (0 or 2 currently).
The non trivial part is that assertions are enabled in debug build of the
*application* but not in the release build. For this something needs to be
done in the application code, it can't be done by the library itself. And
it's IMPLEMENT_APP() which does it -- as this is a macro which is included
in the application. See changes to wx/app.h in the patch.
JS> and how is this specified?
For the library build by using configure --enable-debug=max (which sets
wxDEBUG_LEVEL to 2) or --disable-debug[_flag] option (which sets it to 0).
Under Windows we should probably add it it wx/setup.h (I forgot to do this
to be honest).
For the application by adding -DwxDEBUG_LEVEL=0 to your project options.
JS> Before, you used configure debug switches and knew that they applied
JS> equally to both the library and the app. This difference between app
JS> and library sounds potentially confusing.
Maybe but this is exactly the goal of these changes, from the very
beginning: we want to decouple debugging options of the library and the app
itself. Think about it: what other library requires you to use its debug
build when debugging your own application? All builds of user code should
be able to use normal, default build of wx. This allows to finally have a
single binary (for each platform/compiler/architecture...) and also still
catch user errors without asking them to rebuild wx in debug first.
JS> Personally I (as a wxWidgets user) don't gain any advantages at all from
JS> these changes, because I always compile wxWidgets locally from source
JS> and am quite happy to have debug and release builds.
Indeed, neither you or me are target of these changes. But new and naive
wx users are. I lost count of times when I wrote "if you used debug build
of wx you would have got an assert explaining to you that you use it
wrongly [instead of wasting our time]" and with the new build which does
have asserts always enabled this won't be necessary any more.
JS> I also really don't want wxWidgets assertions popping up in release
JS> builds and would be supprised if anyone else does
This is why they don't by default. I do appreciate your feedback but it
would be really great if you could please read at least the changes to the
documentation included in my patch, I think this is explained quite clearly
there (but if not please let me know).
JS> So unfortunately I get the disadvantages of slower and larger code, and
JS> changing my build system, without any benefits.
You shouldn't have to change your build system. Under Windows the naming
remains the same (there is no choice because of CRT debug/release builds
dichotomy) and under Unix wx-config isolates you from these changes.
JS> I need to be able to tweak my version, so build from source, and would
JS> expect most serious developers to need to do the same.
I think it's very wrong that even you think that wx is unusable in its
default build. This really ought not to be the case.
JS> Hang on a sec, debug information is not even available in the default
JS> library configuration.
Under Unix it isn't, under Windows (with MSVC) it is. I was for enabling
it under Unix as well but didn't do it because you were horrified by the
extra disk space requirements this would entail. I still think we should
build wx with debug info and then use "strip --only-keep-debug" to extract
it in a separate file, just as it's done with PDB under Windows. This will
need some more work though.
JS> Surely any serious programmer is going to want
JS> debug information, so we're back to square one with the developer pretty
JS> much always having to build a debug version, aren't we?
Do you rebuild GTK+ with debug information when you develop using wxGTK? I
admit I do (so I'm a "serious programmer", that's a relief) but 99% of
developers using GTK definitely do not. I don't see why should it be
different for wx.
JS> I really don't want to be negative after all the work you've put into
JS> this - I would like to like it - but on balance this seems confusing,
JS> less-efficient-by-default and with rather minor benefits.
The benefits for us, as wx developers, are huge: we can finally distribute
a single wx version. For users I think having e.g. a simple download of wx
built for Snow Leopard which they could use both when developing and for
production would be quite useful too.
Regards,
VZ
Julian Smart
> On Sun, 06 Sep 2009 11:26:54 +0100 Julian Smart <jul...@anthemion.co.uk> wrote:
>
> JS> > Notice that debug suffix ("d") is not used at all under Unix any more.
> JS> >
> JS> It might be nice if we had a switch e.g. --lib-naming-compatibility that
> JS> would make the libraries named the same way as before,
>
> I think it would only increase the confusion and not really help. Indeed,
> if someone gets an error because they hardcoded the library name with "d"
> in their script/makefile, is it really simpler for them to recompile the
> library with --lib-naming-compatibility or just change their script? I am
> pretty sure it's the latter. The main problem is understanding what you
> need to do but adding this switch won't help with it.
>
> JS> I know you can use wx-config to get the names of most wxWidgets
> JS> libraries but not all libraries are supported, e.g. richtext, and
> JS> makefiles have to make explicit references to the libraries.
>
> Why wouldn't richtext be supported by wx-config? It seems to work fine
> here.
>
> Also, while I agree that in practice some people still don't use wx-config
> I really can't summon much sympathy for them. wx-config is the only
> officially supported way to get wx build options since many, many years.
>
> JS> > For the user programs, there is still a difference between debug and
> JS> > release: in the latter, assertions and debug output are disabled by default
> JS> > (but may both be reenabled). In addition, the user code can be compiled
> JS> > with wxDEBUG_LEVEL set to 0 which would disable any asserts from being
> JS> > compiled in at all in the user code.
> JS> >
> JS> I don't understand this part - how can wxDEBUG_LEVEL have different
> JS> values in the library and user code,
>
> There is no problem with having a different value for a macro (to reply to
> Alec, unlike functions and classes they're not subject to ODR) when
> building the library and the user code. We already do it all the time with
> WXBUILDING (defined when building the library but not when building the
> user code) and WX{MAKING,USING}DLL. The same thing can be done here except
> that it's optional: by default wxDEBUG_LEVEL is 1 but you may change this
> by predefining it to something else (0 or 2 currently).
>
> The non trivial part is that assertions are enabled in debug build of the
> *application* but not in the release build. For this something needs to be
> done in the application code, it can't be done by the library itself. And
> it's IMPLEMENT_APP() which does it -- as this is a macro which is included
> in the application. See changes to wx/app.h in the patch.
>
> JS> and how is this specified?
>
> For the library build by using configure --enable-debug=max (which sets
> wxDEBUG_LEVEL to 2) or --disable-debug[_flag] option (which sets it to 0).
> Under Windows we should probably add it it wx/setup.h (I forgot to do this
> to be honest).
>
> For the application by adding -DwxDEBUG_LEVEL=0 to your project options.
>
> JS> Before, you used configure debug switches and knew that they applied
> JS> equally to both the library and the app. This difference between app
> JS> and library sounds potentially confusing.
>
> Maybe but this is exactly the goal of these changes, from the very
> beginning: we want to decouple debugging options of the library and the app
> itself. Think about it: what other library requires you to use its debug
> build when debugging your own application?
one might use because of how pervasive it is. Sure, you don't usually
need the debug version of GTK+ but that's probably because wxWidgets
mostly protects you from it.
> All builds of user code should
> be able to use normal, default build of wx. This allows to finally have a
> single binary (for each platform/compiler/architecture...) and also still
> catch user errors without asking them to rebuild wx in debug first.
>
wxWidgets release lib in catching such errors.
> JS> Personally I (as a wxWidgets user) don't gain any advantages at all from
> JS> these changes, because I always compile wxWidgets locally from source
> JS> and am quite happy to have debug and release builds.
>
> Indeed, neither you or me are target of these changes. But new and naive
> wx users are. I lost count of times when I wrote "if you used debug build
> of wx you would have got an assert explaining to you that you use it
> wrongly [instead of wasting our time]" and with the new build which does
> have asserts always enabled this won't be necessary any more.
>
> JS> I also really don't want wxWidgets assertions popping up in release
> JS> builds and would be supprised if anyone else does
>
> This is why they don't by default. I do appreciate your feedback but it
> would be really great if you could please read at least the changes to the
> documentation included in my patch, I think this is explained quite clearly
> there (but if not please let me know).
>
> JS> So unfortunately I get the disadvantages of slower and larger code, and
> JS> changing my build system, without any benefits.
>
> You shouldn't have to change your build system. Under Windows the naming
> remains the same (there is no choice because of CRT debug/release builds
> dichotomy) and under Unix wx-config isolates you from these changes.
>
that it's too much of a hassle really.
> JS> I need to be able to tweak my version, so build from source, and would
> JS> expect most serious developers to need to do the same.
>
> I think it's very wrong that even you think that wx is unusable in its
> default build. This really ought not to be the case.
>
with the wxFontDialog problem, I had no alternative but to patch my
source tree and compile against that. The wxRichTextCtrl is less mature
than other parts, so when bugs are fixed in that, I need to use those
changes as soon as possible. wxWidgets is a large and complex system,
written against systems that are always changing, such as Mac OS X. For
standalone libraries such as libjpeg, it's a very different matter - its
context is not changing so fast.
> JS> Hang on a sec, debug information is not even available in the default
> JS> library configuration.
>
> Under Unix it isn't, under Windows (with MSVC) it is. I was for enabling
> it under Unix as well but didn't do it because you were horrified by the
> extra disk space requirements this would entail. I still think we should
> build wx with debug info and then use "strip --only-keep-debug" to extract
> it in a separate file, just as it's done with PDB under Windows. This will
>
> need some more work though.
>
> JS> Surely any serious programmer is going to want
> JS> debug information, so we're back to square one with the developer pretty
> JS> much always having to build a debug version, aren't we?
>
> Do you rebuild GTK+ with debug information when you develop using wxGTK? I
> admit I do (so I'm a "serious programmer", that's a relief) but 99% of
> developers using GTK definitely do not. I don't see why should it be
> different for wx.
>
less mature parts. Or you did something that has a knock-on effect down
the line, which isn't really a wxWidgets bug but you need all the help
you can get. You really need debug info for those moments. As I
mentioned above, you don't tend to need GTK+ debug info because
wxWidgets hides a lot of that for you. But even then there are cases
when GTK+ debug info would be useful, as you find yourself.
I suspect this is an area which is different for different people. If
the standard wxWidgets library will be more helpful, then great, and
I'll try not to grumble at the extra work needed to go back to the
original behaviour (and remember the different debug permutations).
> JS> I really don't want to be negative after all the work you've put into
> JS> this - I would like to like it - but on balance this seems confusing,
> JS> less-efficient-by-default and with rather minor benefits.
>
> The benefits for us, as wx developers, are huge: we can finally distribute
> a single wx version. For users I think having e.g. a simple download of wx
> built for Snow Leopard which they could use both when developing and for
> production would be quite useful too.
>
Right. This assumes that the library will be rock-solid and bug free;
we're definitely closer to that but I think it'll be some years (or
never) before I abandon my local wxWidgets compilation for the standard
version of the library. Maybe the official library will be fine for,
say, 80% of developers until they find they need to use the latest and
possibly patched source, perhaps because they're users of less mature
ports or parts of the library.
Regards,
Julian
Vadim Zeitlin
JS> > Maybe but this is exactly the goal of these changes, from the very
JS> > beginning: we want to decouple debugging options of the library and the app
JS> > itself. Think about it: what other library requires you to use its debug
JS> > build when debugging your own application?
JS> I think wxWidgets is a bit different from most other (smaller) libraries
JS> one might use because of how pervasive it is. Sure, you don't usually
JS> need the debug version of GTK+ but that's probably because wxWidgets
JS> mostly protects you from it.
I don't think this argument really applies to the vast majority of wx
users. Of course, it's true for you and me but we're special (I'm sure GTK+
developers also compile it with debug info and extra debugging much more
often than everyone else).
JS> > You shouldn't have to change your build system. Under Windows the naming
JS> > remains the same (there is no choice because of CRT debug/release builds
JS> > dichotomy) and under Unix wx-config isolates you from these changes.
JS> >
JS> But I guess I would need to make changes to get back the debug info. Not
JS> that it's too much of a hassle really.
If you use --enable-debug when configuring wx it will enable debug info
generation so I don't see why would you need to change anything. True,
debug info is not generated if you don't use --enable-debug but then it
wasn't done before neither. If you build wx yourself the behaviour is
pretty much compatible with what happened before. Unless I made a mistake,
of course, which is why additional review of these changes would be so
welcome.
JS> > JS> I need to be able to tweak my version, so build from source, and would
JS> > JS> expect most serious developers to need to do the same.
JS> >
JS> > I think it's very wrong that even you think that wx is unusable in its
JS> > default build. This really ought not to be the case.
JS> >
JS> It ought not, perhaps, but it really is, at least for me.
...
JS> Right. This assumes that the library will be rock-solid and bug free;
JS> we're definitely closer to that but I think it'll be some years (or
JS> never) before I abandon my local wxWidgets compilation for the standard
JS> version of the library. Maybe the official library will be fine for,
JS> say, 80% of developers until they find they need to use the latest and
JS> possibly patched source, perhaps because they're users of less mature
JS> ports or parts of the library.
This is a problem and it's disheartening that you don't seem to be very
much motivated by fixing it. Maybe, considering that I'm earning my living
as a wx consultant, I just have extremely bad business sense and shouldn't
be trying to make the library work without problems out of the box lest
nobody needs my services any more, but I just don't understand how can you
simply put up with this and say "ok, it doesn't work but I know how to
tweak it so it's fine" :-(
It's completely unrelated to the topic of unifying debug and release
builds but I just don't find this belief that it's somehow ok for wx to be
buggy and unstable acceptable, sorry. There is no law of nature saying that
it should be so and we, wx developers, should be fixing bugs and preventing
the new ones from being introduced instead of meekly accepting them as
inevitable.
Anyhow, to return to the topic at hand, I do agree that debug information
for wx can often be useful and not only for wx developers. Once again, I
was originally for generating it in all builds and you were against it. If
you changed your position now I'd be fine with simply always enabling it. I
think it would be even better to extract it in separate files (at least in
default build) but this can be done later. I'd also welcome any input from
wx packagers for different distributions as I'd like to know how do they
handle it [for other libraries]. I know that Debian has separate dbg
packages containing just the debug information and ideally this is what I'd
like to do: like this the size of the packages containing the libraries
themselves remains reasonable while you can still instead the debug info if
you really need it.
Regards,
VZ
Julian Smart
> I don't think this argument really applies to the vast majority of wx
> users. Of course, it's true for you and me but we're special (I'm sure GTK+
> developers also compile it with debug info and extra debugging much more
> often than everyone else).
>
> JS> > You shouldn't have to change your build system. Under Windows the naming
> JS> > remains the same (there is no choice because of CRT debug/release builds
> JS> > dichotomy) and under Unix wx-config isolates you from these changes.
> JS> >
> JS> But I guess I would need to make changes to get back the debug info. Not
> JS> that it's too much of a hassle really.
>
> If you use --enable-debug when configuring wx it will enable debug info
> generation so I don't see why would you need to change anything.
> ...
> JS> Right. This assumes that the library will be rock-solid and bug free;
> JS> we're definitely closer to that but I think it'll be some years (or
> JS> never) before I abandon my local wxWidgets compilation for the standard
> JS> version of the library. Maybe the official library will be fine for,
> JS> say, 80% of developers until they find they need to use the latest and
> JS> possibly patched source, perhaps because they're users of less mature
> JS> ports or parts of the library.
>
> This is a problem and it's disheartening that you don't seem to be very
> much motivated by fixing it.
> Maybe, considering that I'm earning my living
> as a wx consultant, I just have extremely bad business sense and shouldn't
> be trying to make the library work without problems out of the box lest
> nobody needs my services any more, but I just don't understand how can you
> simply put up with this and say "ok, it doesn't work but I know how to
> tweak it so it's fine" :-(
>
> It's completely unrelated to the topic of unifying debug and release
> builds but I just don't find this belief that it's somehow ok for wx to be
> buggy and unstable acceptable, sorry. There is no law of nature saying that
> it should be so and we, wx developers, should be fixing bugs and preventing
> the new ones from being introduced instead of meekly accepting them as
> inevitable.
>
When I fix something locally, I also fix it in SVN 2.8, and 2.9 if
appropriate, so the fix gets in the next release. Or, I apply a fix that
someone made to SVN 2.8 to my local source tree.
I know I haven't done as much as I should but you don't really think
I've been fixing stuff locally and not contributing back? Apart from
anything else, I'd hate to get out of sync with the next wxWidgets version.
Anyway if I give the impression that I'm not interested in getting
wxWidgets stable I'm sorry, but it's definitely not the case. I just
have to maintain my own source tree so I can fix things as soon as
possible and know that I'm not introducing more potential problems by
downloading a whole new tree. I don't think I'm alone in doing this.
Admittedly, I'm working mainly with 2.8 while 2.9 is in flux; I
occasionally test 2.9 but I wouldn't want to release apps based on it
yet. But I take care to apply my fixes to 2.9.
>
> Anyhow, to return to the topic at hand, I do agree that debug information
> for wx can often be useful and not only for wx developers. Once again, I
> was originally for generating it in all builds and you were against it. If
> you changed your position now I'd be fine with simply always enabling it.
I think that would produce libraries that are too large for standard
wxWidgets distributions, unfortunately.
> I
> think it would be even better to extract it in separate files (at least in
> default build) but this can be done later. I'd also welcome any input from
> wx packagers for different distributions as I'd like to know how do they
> handle it [for other libraries]. I know that Debian has separate dbg
> packages containing just the debug information and ideally this is what I'd
> like to do: like this the size of the packages containing the libraries
> themselves remains reasonable while you can still instead the debug info if
> you really need it.
>
Sounds good.
Regards,
Julian
Stefa...@t-online.de
> > Do you rebuild GTK+ with debug information when you develop using wxGTK? I
> > admit I do (so I'm a "serious programmer", that's a relief) but 99% of
> > developers using GTK definitely do not. I don't see why should it be
> > different for wx.
> >
> Sometimes there are problems in the wxWidgets code, especially in the
> less mature parts. Or you did something that has a knock-on effect down
> the line, which isn't really a wxWidgets bug but you need all the help
> you can get. You really need debug info for those moments.
I think/hope this is only true for a library developper, the normal
user rather turns to the mailing list, I think (and, of course, might
be asked to provide a backtrace, but my impression is that this doesn't
happen very often).
Personally, I tend to rather use the famous printf-Debugger when trying
to undestand/find/fix a wx problem, rather than compiling one of those
unusably huge debug builds. ;-)
> As mentioned above, you don't tend to need GTK+ debug info because
> wxWidgets hides a lot of that for you.
Still if it's a GTK+ problem, it's a GTK+ problem ...
I suppose (some) GTK+ developpers are going to say that one really
needs the GTK+ debug info. ;-)
> I suspect this is an area which is different for different people.
Agreed.
Regards,
Stefan
Vadim Zeitlin
JS> > JS> Right. This assumes that the library will be rock-solid and bug free;
JS> > JS> we're definitely closer to that but I think it'll be some years (or
JS> > JS> never) before I abandon my local wxWidgets compilation for the standard
JS> > JS> version of the library. Maybe the official library will be fine for,
JS> > JS> say, 80% of developers until they find they need to use the latest and
JS> > JS> possibly patched source, perhaps because they're users of less mature
JS> > JS> ports or parts of the library.
JS> >
JS> > This is a problem and it's disheartening that you don't seem to be very
JS> > much motivated by fixing it.
JS> ??
Sorry if I interpreted it wrongly but I read the above as meaning that you
assume, in advance, that people are never going to be able to use wx
without some tweaks to it. I don't find this very encouraging.
Even if it's true now (and I'd like to hope it isn't), I certainly don't
plan to make decisions about the future of wx build/packaging based on this
assumption, it just seems to be self-defeating.
So, as apparently this need to be said, I do hope that we will be able to
make wx 3.0 binary release (at least in form of various Unix packages and
hopefully also prebuilt versions for MSVCn (for some value of n)) which
will be usable without any fatal problems. And both Unicode changes and
these debug-related changes will help with making it easier for both us and
our users.
Regards,
VZ
iko...@earthlink.net
-----Original Message-----
>From: Vadim Zeitlin <va...@wxwidgets.org>
>Sent: Sep 6, 2009 6:49 AM
>To: wx-...@googlegroups.com
>Subject: [wx-dev] Re: ALL: review of debug patch wanted
>
>On Sun, 06 Sep 2009 11:26:54 +0100 Julian Smart <jul...@anthemion.co.uk> wrote:
>
>JS> > Notice that debug suffix ("d") is not used at all under Unix any more.
>JS> >
>JS> It might be nice if we had a switch e.g. --lib-naming-compatibility that
>JS> would make the libraries named the same way as before,
>
> I think it would only increase the confusion and not really help. Indeed,
>if someone gets an error because they hardcoded the library name with "d"
>in their script/makefile, is it really simpler for them to recompile the
>library with --lib-naming-compatibility or just change their script? I am
>pretty sure it's the latter. The main problem is understanding what you
>need to do but adding this switch won't help with it.
What about people that use MS Visual Studio workspace/solution?
I know I use VC6 with .dsw and going through changing every single library
name in every single project... This at least has to be documented somewhere.
Thank you.
Vadim Zeitlin
> What about people that use MS Visual Studio workspace/solution?
> I know I use VC6 with .dsw and going through changing every single library
> name in every single project...
The "d" suffix remains under Windows, although its meaning changes (it now
indicates that the library is linked with debug CRT libraries and not that
it contains debug support code or is built with debug information as this
is now true for both "d" and "d"-less versions). So there is nothing to
change and nothing to document.
Regards,
VZ
Alec Ross
> There is no problem with having a different value for a macro (to reply to
>Alec, unlike functions and classes they're not subject to ODR) when
>building the library and the user code.
I was concerned that the macro value might be used somehow to
conditionally include different definitions of classes or functions -
perhaps indirectly. And of course hoped not, and that my question was
not too much noise.
A
--
Alec Ross
Vadim Zeitlin
AR> > There is no problem with having a different value for a macro (to reply to
AR> >Alec, unlike functions and classes they're not subject to ODR) when
AR> >building the library and the user code.
AR>
AR> I was concerned that the macro value might be used somehow to
AR> conditionally include different definitions of classes or functions -
AR> perhaps indirectly.
Sorry, I was indeed too quick. While there is no problem with
wxDEBUG_LEVEL itself and ODR, we do have such problem with any inline
functions using wxASSERT (or related macros) which may be defined
differently depending on how wxDEBUG_LEVEL is defined.
To be honest I'm not sure what to do about it. The safest thing to do
would be to move all these asserts out of the headers and this was indeed
my original plan. But OTOH in practice this ODR violation is unlikely to
result in any problems and so far I didn't find any in my testing. So I'm
tempted to leave it as is for now knowing that if ever does become a real
problem we do have the solution of removing the asserts from the headers.
Regards,
VZ
iko...@earthlink.net
-----Original Message-----
>From: Vadim Zeitlin <va...@wxwidgets.org>
>Sent: Sep 6, 2009 3:43 PM
>To: wx-...@googlegroups.com
>Subject: [wx-dev] Re: ALL: review of debug patch wanted
>
>On Sun, 6 Sep 2009 11:09:27 -0700 (GMT-07:00) iko...@earthlink.net wrote:
>
>> What about people that use MS Visual Studio workspace/solution?
>> I know I use VC6 with .dsw and going through changing every single library
>> name in every single project...
>
> The "d" suffix remains under Windows, although its meaning changes (it now
^^^^^^^^^^^^^^^^^^
If this is clearly stated somewhere, then I think people that will be using MSVC
under Windows will be happy.
And I guess for Borland/mingw32/Watcom builds on Windows everything will be the
same as under *nix as they will use wx-config, right? Because I know, at least Borland
currently uses Makefile and you can't build wx under Borland IDE (there is no Borland
project files currently).
Am I correct?
Sorry if I keep asking about same thing, but I personally use MSVC, and tried Borland
compilation only once, so I want to make sure everything will be good and different people
will be able to use different build system.
Thank you.
> Regards,
>VZ
Vadim Zeitlin
> And I guess for Borland/mingw32/Watcom builds on Windows everything will be the
> same as under *nix as they will use wx-config, right?
No, my changes don't change anything here and the makefiles are still used
for Borland/Watcom. For mingw32 I don't actually know which CRT do
makefiles use but still nothing should change for it, only naming of the
libraries produced by msys/configure will change as they won't have "d" any
longer.
Regards,
VZ
iko...@earthlink.net
-----Original Message-----
>From: Vadim Zeitlin <va...@wxwidgets.org>
>Sent: Sep 6, 2009 6:05 PM
>To: wx-...@googlegroups.com
>Subject: [wx-dev] Re: ALL: review of debug patch wanted
>
>On Sun, 6 Sep 2009 19:36:23 -0400 (EDT) iko...@earthlink.net wrote:
>
>> And I guess for Borland/mingw32/Watcom builds on Windows everything will be the
>> same as under *nix as they will use wx-config, right?
>
> No, my changes don't change anything here and the makefiles are still used
>for Borland/Watcom.
But what about naming of the libraries? I guess they should follow the same naming
convention as for the MSVC, right?
> For mingw32 I don't actually know which CRT do
>makefiles use but still nothing should change for it, only naming of the
>libraries produced by msys/configure will change as they won't have "d" any
>longer.
Ok, and they will have a debug info by default, correct?
Also, I think I didn't forget any other Windows compiler... ;-)
Thank you.
>
> Regards,
>VZ
Eric Jensen
i have to admit that i didn't 100% understand the changes, so i'd just
like to ask one thing:
Will it be possible (with a setting in SETUP.H and/or compiler settings)
to get the old (=current) behavior back?
I'm using VS2003.
Thanks,
Eric
Vadim Zeitlin
EJ> i have to admit that i didn't 100% understand the changes, so i'd just
EJ> like to ask one thing:
EJ> Will it be possible (with a setting in SETUP.H and/or compiler settings)
EJ> to get the old (=current) behavior back?
Yes, you will need to define wxDEBUG_LEVEL as 0 in wx/setup.h and also
define it as 0 yourself in release build to completely disable all the
assertions.
Regards,
VZ
Julian Smart
equivalent of setting wxDEBUG_LEVEL to 0? It would be nice to be able to
adjust these settings from the command line, especially for automation
via IDEs.
Thanks,
Julian
Vadim Zeitlin
JS> Is passing DEBUG_INFO=0 to the wxWidgets makefile under Windows the
JS> equivalent of setting wxDEBUG_LEVEL to 0?
No, DEBUG_INFO governs debug information generation. To set wxDEBUG_LEVEL
to 0 you need DEBUG_FLAG=0 (again, this is the same as before, nothing
changed except that you now _may_ use DEBUG_FLAG=1 even with
DEBUG_RUNTIME_LIBS=0 whereas before they had to be equal).
Regards,
VZ
Julian Smart
assertions as per the current situation, do I need to do:
make BUILD=release
or
make BUILD=release DEBUG_FLAG=0
? Just wondering if DEBUG_FLAG=0 is implied by specifying the BUILD
value explicitly rather than letting it take the default value, as I
think you've done with the configure case.
Thanks,
Julian
Vadim Zeitlin
JS> OK, thanks. Just to clear up the last drop of confusion, if I want no
JS> assertions as per the current situation, do I need to do:
JS>
JS> make BUILD=release
JS>
JS> or
JS>
JS> make BUILD=release DEBUG_FLAG=0
JS>
JS> ?
The latter.
JS> Just wondering if DEBUG_FLAG=0 is implied by specifying the BUILD
JS> value explicitly rather than letting it take the default value, as I
JS> think you've done with the configure case.
Setting DEBUG_FLAG=0 by default would make the behaviour inconsistent with
Unix version and kind of defeated the entire purpose of these changes so
the default is 1. BUILD selects DEBUG_RUNTIME_LIBS only (and DEBUG_INFO
with non-MSVC compilers).
Regards,
VZ
Robin Dunn
> Hello,
>
> I've implemented the changes to debug facilities in wx discussed (well,
> mostly monologued about by me) before and would like to request comments
> about the patch at http://trac.wxwidgets.org/ticket/11175
I'm still catching up on the rest of the conversation but in the
meantime I thought I would let you know that I've reviewed that patch
and it looks good to me. There is nothing that jumps out as being a
potential problem for wxPython.
--
Robin Dunn
Software Craftsman
http://wxPython.org
Vadim Zeitlin
RD> Vadim Zeitlin wrote:
RD> > Hello,
RD> >
RD> > I've implemented the changes to debug facilities in wx discussed (well,
RD> > mostly monologued about by me) before and would like to request comments
RD> > about the patch at http://trac.wxwidgets.org/ticket/11175
RD>
RD> I'm still catching up on the rest of the conversation but in the
RD> meantime I thought I would let you know that I've reviewed that patch
RD> and it looks good to me. There is nothing that jumps out as being a
RD> potential problem for wxPython.
Thanks a lot for reviewing it, wxPython was one of the things I was
worrying about.
Another one were wxpresets which were not modified by the patch. But since
then I did update them basically by just removing (and silently ignoring)
WX_DEBUG option from Unix (i.e. gnu and autoconf) presets and this seems to
work fine for my own programs.
If no other big problems are found with this patch I'm probably going to
commit it towards the end of the week.
Thanks again,
VZ
Ger Hobbelt
> Hello,
>
> I've implemented the changes to debug facilities in wx discussed (well,
> mostly monologued about by me) before and would like to request comments
> about the patch at http://trac.wxwidgets.org/ticket/11175
>
>
> For those who didn't follow the previous discussions, let me briefly
> (re)describe the changes:
Thanks for the summary; I'm following this as time allows.
Critique: none so far. I applaud the move.
One nitpick: one typo glared at me in debugging.h @ #26:
@section overview_debugging_config Configuing debugging support
--> missing 'r':
@section overview_debugging_config Configuring debugging support
One bit of hmmmm: I'll have to see it more up close and personally in
my own environment to see whether it simplifies the following (out of
scope?) scenario: using wxASSERTions in wx-related sections of my own
application code, using either wxw-defined assertion backend code or
custom defined alternatives. (I use the first, but only because I've
been lazy/in a hurry when doing work which involved wxw so far.) When
I got this right, simply setting the wxDEBUG_LEVEL define to the
correct level will allow me to keep my 'in-app assertions' alive in
any build, even when wxw itself was compiled with a different level.
Now all I need to doublecheck is whether the code behind the macros
will be 'alive' when we do something like that...
By the way:
1) I use wxw with 'augmented' MSVC project files and a few tweaks and
build from source. Why? Because I have a very strict build environment
and the wxw project files are made to fit in that env. Besides,
building from source in an all-from-source build setup on MSVC/Windows
prevents us from stumbling across a few nasty DLL Hell gotchas (dbg
vs. release RTLs, /MT yes/no, etc.) when the pressure is on due to a
release date. Building may take longer, but it removes a few nasty WTF
stress moments just before D-Day.
2) why I applaud this move:
having 'debug' (or rather: diagnostics) code (~ assertions) active at
all times is beneficial to both dev and user. I know there are some
s/w users out there who never got that this support folks' tale was
meant as a joke:
"Hello, support desk. How can we help?"
"Nothing works around here."
"Can you be a bit more specific, please?"
"Okay... /Absolutely/ nothing works around here."
and those folks will discard anything you feed them, unless it's the
Final Solution(tm). However, I've found (as a commercial s/w eng.)
that most users are perfectly willing to learn a few things like
"screendump", etc. when they guess it might help you help them.
Assertion failure reports, even the, ah, somewhat cryptic ones, are
more helpful (as long as you can say 'ignore and continue, you !@#$%^"
to them, as a user) then just not having them and getting an
unfortunate support request stating "it started to act weird and I
don't know what I did wrong or where it went wrong". I've seen enough
of those in commercial environments over the years, often because
'release' builds are stripped of all and any diagnostics code (which
is often mistook for 'debug info'). I'm glad I now can have run-time
sensibility checks in wxw release builds too.
Mind you, I'm not in favor of /always/ keeping assertions live, but
wxw is a 'convenience' library rather than a lib where 'speed' is top
priority (such as one might find for data processing libs). Only the
latter type 'benefits' from stripping in-line run-time diagnostics
such as assertions, to give it that extra bit of oompf in the final
product, but this requires a different level of testing rigor as well,
which is hard to accomplish for UIs. In a 'convenience' (UI) library,
as long as the assertions don't eat up a major chunk of cpu time,
they're perfectly fine to have around 24/7.
3) I'd rather hear the complaints about having to click 'ignore' on
three 'useless' assertion dialogs when doing task X, than not hearing
about it, apart from loads of vague grumbles about 'crap'. The former
serves both users and management in a positive way, as it's making a
clearly visible noise about a given part of the software not having
been tested(-->developed/designed) well enough. Those assertions serve
as political leverage: the incentive to improve the solidity of the
s/w increases accordingly.
My 2 cents. Thanks for everything!
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------
Vadim Zeitlin
GH> Thanks for the summary; I'm following this as time allows.
GH>
GH> Critique: none so far. I applaud the move.
Thanks for looking at this!
GH> One nitpick: one typo glared at me in debugging.h @ #26:
GH>
GH> @section overview_debugging_config Configuing debugging support
GH>
GH> --> missing 'r':
Argh, bad Vim, bad. Why doesn't it check spelling in Doxygen sections
headers? I had to copy doxygenSpecialSectionDesc definition into my own
~/vim/syntax/doxygen.vim and modify it to contain "@Spell" to make this
work. I wonder if there is a better solution... Anyhow, thanks for noticing
this typo and there should be no more of them now that my Vim does keep an
eye on this.
GH> One bit of hmmmm: I'll have to see it more up close and personally in
GH> my own environment to see whether it simplifies the following (out of
GH> scope?) scenario:
No, it's not out of scope because it's quite common.
GH> using wxASSERTions in wx-related sections of my own
GH> application code, using either wxw-defined assertion backend code or
GH> custom defined alternatives. (I use the first, but only because I've
GH> been lazy/in a hurry when doing work which involved wxw so far.) When
GH> I got this right, simply setting the wxDEBUG_LEVEL define to the
GH> correct level will allow me to keep my 'in-app assertions' alive in
GH> any build, even when wxw itself was compiled with a different level.
Yes, and by default your assertions will remain enabled which, I believe,
is the right thing to do. The only difference is that while they show an
assert message box in debug builds, they do nothing, by default, in
release. But I recommend using wxSetAssertHandler() to change this and at
least log a message to your program log file about this or maybe throw an
exception which could then be caught and logged at the top level.
GH> Mind you, I'm not in favor of /always/ keeping assertions live, but
GH> wxw is a 'convenience' library rather than a lib where 'speed' is top
GH> priority (such as one might find for data processing libs). Only the
GH> latter type 'benefits' from stripping in-line run-time diagnostics
GH> such as assertions, to give it that extra bit of oompf in the final
GH> product, but this requires a different level of testing rigor as well,
GH> which is hard to accomplish for UIs. In a 'convenience' (UI) library,
GH> as long as the assertions don't eat up a major chunk of cpu time,
GH> they're perfectly fine to have around 24/7.
Unsurprisingly, I happen to think in the same way...
Regards,
VZ