Question on unification of Debug and Release builds in 3.0
arnholm
Reading the Roadmap http://trac.wxwidgets.org/wiki/Roadmap I find that
in 3.0 the Debug and Release builds will be the same. This I do not
quite understand and it worries me that such a model model seems quite
different from normal practice (with Debug and Release). Always
including Debug support will result in bigger and slower
executables....?
But maybe I am missing something? If so, what?
I use VC2008 as my compiler on Windows today. I build the libraries
myself in Debug and Release mode using the supplied wx.dsw files, and
I really want to continue doing that. Will I be able to?
I also use Debug and Release builds on Linux and have similar worries.
--
Carsten A. Arnholm
http://arnholm.org/
N59.776 E10.457
Vadim Zeitlin
a> Reading the Roadmap http://trac.wxwidgets.org/wiki/Roadmap I find that
a> in 3.0 the Debug and Release builds will be the same.
This is not quite true. Under Windows you will still have debug and
release builds because they differ by the CRT build they use (e.g. with
MSVC you use /MT or /MD for the release build but /MTd or /MDd for the
debug one). However from wx point of view they will be the same: e.g. they
will both include assertions and will also both generate debug information.
a> This I do not quite understand and it worries me that such a model model
a> seems quite different from normal practice (with Debug and Release).
a> Always including Debug support will result in bigger and slower
a> executables....?
This depends on what you mean by debug support. If you mean debug
information then it's generated in separate PDB files by MSVC and so has no
bearing whatsoever on executable size nor speed. If you mean assertions,
then you're right, preserving them in release build will make the
executable slightly (~5%) larger and marginally slower. But I think the
gain is worth it.
a> I use VC2008 as my compiler on Windows today. I build the libraries
a> myself in Debug and Release mode using the supplied wx.dsw files, and
a> I really want to continue doing that. Will I be able to?
Yes.
a> I also use Debug and Release builds on Linux and have similar worries.
Under Linux (or any Unix system, including OS X) there is just one libc
and so the situation is much better/simpler: you can use exactly the same
build of wx for both developing and production. So while you can keep
building "debug" and "release" versions they will be practically
indistinguishable (except that debug one will be larger because it does
include debug info in the library files themselves while we don't generate
debug info for the release build under Unix until we implement splitting it
out from the library files as it's done by MSVC). So you should simply be
always using the normal, default wx build there.
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Riccardo Cohen
There are many optimizations options on visual studio, and at least one
mainly used on unix (-O3). In general compiling confs do not use these
optimizations in debug mode.
As long as I developped, I never used optimization on debug version, and
I beleive that some code will be more difficult to debug if there are
some hard optimization during compilation. maybe I'm wrong (if not why
are these optimizations optional ?)
It is true that modern languages tend to remove this notion (for
instance in sun java), but 1) these languages generate bytecode not
assembler, 2) as3 compiler has a debug flag at compile time, and even
ibm java compiler has a -O option for optimization.
The wiki page http://trac.wxwidgets.org/wiki/DebugRelease does not
explain the reason for this choice. Could it be added ?
--
Riccardo Cohen
Architecte du Logiciel
http://www.architectedulogiciel.fr
+33 (0)6.09.83.64.49
Membre du réseau http://www.reflexe-conseil-centre.org
Vadim Zeitlin
RC> As long as I developped, I never used optimization on debug version, and
RC> I beleive that some code will be more difficult to debug if there are
RC> some hard optimization during compilation. maybe I'm wrong (if not why
RC> are these optimizations optional ?)
The main reason for disabling optimizations is that they significantly
increase the compilation time. But you're right that optimized code is also
more difficult to debug. However I don't see why should it matter to you,
application developer: normally you don't debug wxWidgets itself.
RC> The wiki page http://trac.wxwidgets.org/wiki/DebugRelease does not
RC> explain the reason for this choice. Could it be added ?
There are 2 important reasons:
1. Make sure asserts are always there as they are very useful when
developing with wx and I can't count the number of hours/days/years
wasted on some bug whose cause would have been immediately obvious
if asserts were enabled.
2. Cut down further on number of packages: with 2.9.1 under Unix we can
only have one, optimized Unicode build, instead of four debug/release
ANSI/Unicode builds which we needed with 2.8 or two debug/release ones
with 2.9.0.
Riccardo Cohen
long as there is an option in wx build command to continue debug as
usual, I agree with the argument about asserts and packages.
thanks for the info.
--
Graeme Gill
> The main reason for disabling optimizations is that they significantly
> increase the compilation time. But you're right that optimized code is also
> more difficult to debug. However I don't see why should it matter to you,
> application developer: normally you don't debug wxWidgets itself.
Another reason is to diagnose compiler optimization bugs.
Graeme Gill.
klaas.holwerda
> Under Linux (or any Unix system, including OS X) there is just one libc
> and so the situation is much better/simpler: you can use exactly the same
> build of wx for both developing and production.
time. Will at least the naming be different?
So i can use wx-config to choose one or the other?
I find it very useful to debug into wxWidgets, but i use non debug for
speed. I am not sure why the speed is much different (drawing huge
amounts of data), it might well be my own problem, since i change
behaviour to make debugging easier.
Until now i just assumed it was being having debug info in the files.
> So while you can keep
> building "debug" and "release" versions they will be practically
> indistinguishable (except that debug one will be larger because it does
> include debug info in the library files themselves while we don't generate
> debug info for the release build under Unix
>
That i would not find convenient. For all wxWidgets dependencies (wxLua,
wxArt2D, wxCode stuff) will suffer the same problem. They now have
different naming. So can be all installed (debug and release) in
/usr/local without a problem.
Klaas
Nathan Ridge
<E1N5pQn-...@smtp.tt-solutions.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
----------------------------------------
> Date: Thu=2C 5 Nov 2009 00:38:25 +0100
> From: va...@wxwidgets.org
> Subject: Re: Question on unification of Debug and Release builds in 3.0
> To: wx-u...@googlegroups.com
> This depends on what you mean by debug support. If you mean debug
> information then it's generated in separate PDB files by MSVC and so has =
no
> bearing whatsoever on executable size nor speed. If you mean assertions=
=2C
> then you're right=2C preserving them in release build will make the
> executable slightly (~5%) larger and marginally slower. But I think the
> gain is worth it.
Why not give the option to exclude assertions from the release build for th=
e benefit of those who do care about the decrease in efficiency=2C however =
slight?
=20
Regards=2C
Nate. =20
_________________________________________________________________
Windows Live: Keep your friends up to date with what you do online.
http://go.microsoft.com/?linkid=3D9691815=
Vadim Zeitlin
NR> Why not give the option to exclude assertions from the release build for th=
NR> e benefit of those who do care about the decrease in efficiency=2C however =
NR> slight?
There is such option (--disable-debug or wxDEBUG_LEVEL=0) but it's not the
default.
Vadim Zeitlin
k> Vadim Zeitlin wrote:
k> > Under Linux (or any Unix system, including OS X) there is just one libc
k> > and so the situation is much better/simpler: you can use exactly the same
k> > build of wx for both developing and production.
k> Nice, but i use both debug and release builds of wxWidgets at the same
k> time. Will at least the naming be different?
No but you can use your own flavour (--with-flavour=debug) to change this.
k> So i can use wx-config to choose one or the other?
Only by specifying flavour explicitly.
k> I find it very useful to debug into wxWidgets, but i use non debug for
k> speed.
Ideally we'd support debugging the normal version by generating separate
.debug files with debug information. Unfortunately this hasn't been done
yet.
k> Until now i just assumed it was being having debug info in the files.
No, having debug info doesn't affect the speed at all. Disabling
optimizations (including inlining) does have dramatic performance
consequences and this is done in debug builds currently.
k> So i can not have both side by side installed?
k> That i would not find convenient. For all wxWidgets dependencies (wxLua,
k> wxArt2D, wxCode stuff) will suffer the same problem. They now have
k> different naming. So can be all installed (debug and release) in
k> /usr/local without a problem.
And this is something that no other library does under Unix AFAIK. wx has
simply copied this behaviour from Windows but there it makes sense (and is
in fact necessary) because you have debug and release CRT versions. Under
Unix you don't, so why would you want to do this?
Vaclav Slavik
On Fri, 2009-11-06 at 00:02 +0100, Vadim Zeitlin wrote:
> Ideally we'd support debugging the normal version by generating
> separate .debug files with debug information. Unfortunately this
> hasn't been done yet.
I said it in the past and I'll repeat it: splitting the debug stuff out
of the ELF binary into separate files and a separate package is
distributions' job, not ours.
They have different rules for doing it, they'll use their own mechanisms
when creating packages (ignoring any bakefile/wx-provided support)
anyway and it only makes sense to split debug info out when packaging.
Plus, they already *have the code*, so I fail to see the point of
duplicating all that in Bakefile or wx.
Regards,
Vaclav
Vadim Zeitlin
VS> On Fri, 2009-11-06 at 00:02 +0100, Vadim Zeitlin wrote:
VS> > Ideally we'd support debugging the normal version by generating
VS> > separate .debug files with debug information. Unfortunately this
VS> > hasn't been done yet.
VS>
VS> I said it in the past and I'll repeat it: splitting the debug stuff out
VS> of the ELF binary into separate files and a separate package is
VS> distributions' job, not ours.
This is an appealing point of view especially because it means we don't
have anything to do. But I'm unsure how useful is this in practice, i.e.
how long will we need to wait until this happens.
VS> and it only makes sense to split debug info out when packaging.
Under Windows it may be very helpful to have PDBs for an app normally
shipping without them. I don't know if it's as useful under Unix/Linux
because I've never tried it but in principle I think it could be nice to
build the release versions of the app and static release libs it uses but
split the debug information in .debug files.
VS> Plus, they already *have the code*, so I fail to see the point of
VS> duplicating all that in Bakefile or wx.
I think above is one reason -- Debian is never going to package closed
source applications. And, speaking of Debian, we'd still need to do this
ourselves for it anyhow...
Vaclav Slavik
On Fri, 2009-11-06 at 14:01 +0100, Vadim Zeitlin wrote:
> VS> I said it in the past and I'll repeat it: splitting the debug stuff out
> VS> of the ELF binary into separate files and a separate package is
> VS> distributions' job, not ours.
>
> This is an appealing point of view especially because it means we don't
> have anything to do. But I'm unsure how useful is this in practice, i.e.
> how long will we need to wait until this happens.
There must be some misunderstanding. All major distributions *already*
do it. Their respective package creation tools make it trivial to
produce -debug, -dbg or such packages together with the "main" packages.
Perhaps I should have phrased it that "it is distributions' job to
provide packaging tools that split debuginfo out in distro-appropriate
way". The point is, the tools are already there and at your disposal,
writing some more would be waste of time.
> because I've never tried it but in principle I think it could be nice to
> build the release versions of the app and static release libs it uses but
> split the debug information in .debug files.
Yes. As I said, this already happens. When you build a package for
deployment, rpm -- to name just one example -- will create debuginfo
package(s) for you. So the only people who would have any use for doing
this in wx itself would be those cruel folks who ship proprietary
binaries in plain tarball instead of in proper packages. They can just
as well add the relevant command or two to their packaging scripts.
> VS> Plus, they already *have the code*, so I fail to see the point of
> VS> duplicating all that in Bakefile or wx.
>
> I think above is one reason -- Debian is never going to package closed
> source applications.
But it does -- and will -- provide you with dpkg-buildpackage even if
you use it to build closed-source packages.
> And, speaking of Debian, we'd still need to do this
> ourselves for it anyhow...
Fortunately, it's trivial: http://ze-dinosaur.livejournal.com/7036.html
Vaclav
Kenneth Porter
<vsl...@fastmail.fm> wrote:
> Yes. As I said, this already happens. When you build a package for
> deployment, rpm -- to name just one example -- will create debuginfo
> package(s) for you.
In fact, I'm doing this right now.
The bad part is that most distro mirrors don't carry the -debug packages
(due to size constraints) and you need the source package anyway for them
to be useful. So download the source package (.src.rpm) and build it on
your system using "rpmbuild --rebuild xxx.src.rpm". Install both the
regular and -debug packages. Then debug your app and it will find the wx
source where your rpm-builder left the source when it rebuilt the package.
(This can be the same user that builds your app, or a special user just for
that purpose. Just make sure the source is accessible by setting the
permissions on the rpm-builder's home directory appropriately.)