I have tried the patch used in Debian for this... it works but, for some reason, I see this error on start (even if later it seems to work ok): /var/tmp/portage/x11-libs/wxGTK-3.0.2.0-r1/work/wxPython-src-3.0.2.0/src/gtk/textctrl.cpp(847): assert "IsSingleLine()" failed in GetEditable(): shouldn't be called for multiline I wonder why Debian and Arch look to not hit this, maybe our wxGTK package is bogus... but after reviewing it I haven't found anything :(
Umm, I see in other Debian package this: ++# Define NDEBUG to disable wxWidgets 3.0 debug mode to avoid a lot of assertion ++# failed dialogs. While it would be better to actually fix the causes of ++# these, if NDEBUG is defined, then these conditions are handled quietly, just ++# like wxWidgets 2.8 did by default. ++WXCXXFLAGS= `$(WXCONFIG) --cxxflags` -MMD -DNDEBUG ++WXLDFLAGS = -Wl,--as-needed `$(WXCONFIG) --libs std,aui` Maybe that is the cause
http://docs.wxwidgets.org/3.0.0/overview_debugging.html Yeah, that would explain this issues we are getting in Gentoo as our ebuild default to enabling that debugging at level "1" always, witch end up with that ugly error dialogs popping up instead of simply dropping the errors in the terminal and behaving like in 2.8 :| @wxwidgets, should we maybe disable debugging completely in wxGTK ebuild? (taking advantage of the "debug" USE flag the ebuilds already have)
If we disabled debugging on the wxGTK side then no package building against it would get debugging info no matter what they did. The way it used to work you had to rebuild the library and then every single package linking against it (because the lib names changed), and you got debug info in all or none of them. I really don't want to go back to that. Now you only need to rebuild the package you're interested in. Using -DNDEBUG is the correct solution here. We can make this a little easier though. I don't want every wxGTK-using package require a debug USE flag, so why don't we make the eclass append -DNDEBUG when it's missing or exists and is disabled?
That would be an option and it looks ok to me :) My main concern with current behavior is that it will be really really hard to ensure every reverse dep won't show this ugly error dialogs when, for example, some user will open some concrete submenu and toggle one concrete option. I mean, in some cases we catch easily the errors as they are shown in start, but in others they will appear only in some corner cases that will be hard to detect in advance
[master f3072f3] dev-vcs/rapidsvn: Support wxGTK:3.0 (#563348) 2 files changed, 318 insertions(+) create mode 100644 dev-vcs/rapidsvn/files/rapidsvn-0.12.1-wx3.0.patch create mode 100644 dev-vcs/rapidsvn/rapidsvn-0.12.1-r2.ebuild
