Possibility to build "RelWithDebInfo" Qt on Windows

[Stinkfist0]

It's not that uncommon to crash within Qt in RelWithDebInfo builds. Add possibility to build "RelWithDebInfo" Qt in addition to plain release and debug on Windows in order to be able to investigate the crashes more conveniently.

[jonnenauha]

Whats the point of this? Why would you just not build the deps and Tundra in debug? :P

[Stinkfist0]

You would rather choose performing this:

1. Running RelWithDebInfo as usual
2. Play around
3. Crash
4. Attach to VS JIT debugger
5. Crash in QtModule.dll -> hmm why and where here?
6. Stop debugging
7. BuildDeps_Debug.cmd (must be done always currently unfortunately), wait couple mins in the best best case, couple hours in the worst case (if not run before)
8. Build Debug Tundra (0-30 min)
9. Start (slow) Debug Tundra
10. Play around
11. Crash
12. Attach to JIT debugger
13. Crash in QtSomeModule.dll -> Ok it crashed in this function and this line here (with full variable info etc.)!
14. Start figuring it out.

over this:

1. Running RelWithDebInfo as usual
2. Play around
3. Crash
4. Attach to VS JIT debugger
5. Crash in QtSomeModule.dll -> Ok it crashed in this function and this line here (with partial variable info etc.)!
6. Start figuring it out.
   (7. if needing full info of the values of the variables etc. build Debug build..)

[jonnenauha]

Right i guess you have a good point. I just built Qt5 for fun at home and noticed there was some kind of -debuginfoinrelease or similar to do just this. Hopefully its present also in Qt4 configure.exe.

The problem this will then bring is that when you dev with RelWithDebInfo and want to make a release, youd have to build Qt again. Not sure if its a complete rebuild, but the debug info DLLs would be the release DLLs, there is no RelWithDebInfo subfolders etc. in the Qt build to keep multiple release builds next to each other.

Though if you have semi.new debug and relwithdeb builds of Tundra lying around, the deps + tundra build wont be 30 minutes, in a perfect world :)

[Stinkfist0]

As far as Windows/MSVC CMake's default build config settings go, RelWithDebInfo is perfectly good for releases, and Release doesn't provide anything that significantly boosts the peformance; AFAIK the only real difference is a bit more aggressive inlining in Release and RelWithDebInfo causes some insignificant size overhead the the binaries.

I haven't looked closely to Qt's release and release + debug information build configuration setting differences on Windows, but I doubt there would be anything significant in the area.

I think RelWithDebInfo for Tundra (at minimum) and dependencies (maybe not the crucial) would be preferred for releases anyways for proper minidumps and possibility to debug them - a possibility that we don't unfortunately currently use with Rocket Windows releases. We could always throw in some extra optimization (e.g. that more aggressive inlining) on top of that if feeling the urge.

[jonnenauha]

Insignificant size overhead? Thats a joke right? :) I'm sure you are downplaying the optimized release flags on both the compiler and linker quite a bit also...

So you would not care if eg. Meshmoon ships ~50-100mb bigger DLLs (in total) and miss out of faster code just because you didn't want to flip some switches and rebuild? :P I use RelWithDebInfo all the time while devving but lets not get carried away that this is what we should send to end users.

Also if you wish your end users to start sending minidumps over email or otherwise manually thats not a "perk". Once we get a proper system to automatically send crash dumps I could consider moving to Release with such flags after carefully examining what stuff needs to be enabled and what impact it will have. Full RelWithDebInfo is still not necessary even if you want minidumps and stack traces.

[Stinkfist0]

See for example http://stackoverflow.com/a/6364789 I haven't compared the Tundra/Rocket Release and RelWithDebInfo binary sizes recently, so can't remember those exactly, but as far as I remember, the differences were quite small.

[jonnenauha]

Thats just what I said. This guy found a custom set of flags for probably both linker and the compiler to get debug info but still not that much bigger binary. /OPT:NOREF etc is certainly not a default flag in RelWithDebInfo, its not even in Release afaik. What you seem to be proposing is a plain old RelWithDebInfo is not a lot bigger, which it certainly is. Even his 25% figure with the amount of DLLs Tundra/Meshmoon ships build up to significant size.

But no debug info should be added before there is automated crash reporter that works and send this stuff automatically. At most a yes/no dialog to the end user, if it gets more complicated than that then for me its a no go, and imo debug info is totally useless.

Edit: I dont know why this railed to shipping DLLs to users. I said enabling the Qt debug info for developers is good idea. But I would never send them to end users, but thats a simple build away and does not say we should not do it.

[Stinkfist0]

Haha, yes going quite off-topic here. Used a bit bad wording earlier: what I tried to say that when considering performance, firstly, RelWithDebInfo is not really inferior to Release, and, secondly, in the context of the Tundra application as a whole, the extra sizes of the binaries can be seen as insignificant, when factoring in the the crash debugging capability. The official Rocket release seems to be around 322 MB uncompressed, so for it example, say, 10-20 MB overhead would not really make a difference, but of course smaller size would not hurt.

I would see beneficial to have some kind of FORCE_USE_RELEASE_DEPS build option in order to be easily build Tundra as RelWithDebInfo but use the smaller Release binaries for the dependencies if wanted. Thus debugging at least crashes in our own code would be possible.

BTW, I quickly checked out the file sizes of Rocket VC9 x86 release (Release + ENABLE_BUILD_OPTIMIZATIONS) [1] versus Rocket VC10 x86 nightly (RelWithDebInfo + ENABLE_BUILD_OPTIMIZATIONS) [2].

[1] 23 plug-ins  14.4 MB
[2] 23 plug-ins  14.3 MB

OK, looking nice. I'd assume that VC9 RelWithDebInfo + ENABLE_BUILD_OPTIMIZATIONS would produce slightly larger binaries here as VC10 is know to produce smaller binaries compared to VC9 in general. Looking for the biggest difference I see:

[1] OgreMain.dll    6.8 MB
[2] OgreMain.dll    10.2 MB

That's quite a significant difference!

Also noticed that Qt DLLs built with VC9 are slightly smaller than the ones built VC10, which is a bit surprising as typically VC10 has been observed to produce smaller binaries. Would be interesting also to check out the "RelWithDebInfo" sizes for Qt DLLs.

It would also be interesting to run fully comparable VCX Release vs. VCX RelWithDebInfo tests for the file sizes.

[Stinkfist0]

But back to the original issue: if/when this possibility would exists, yeah, it would be great to make Qt build process to deploy the binaries into separate debug, release, and release-with-debug-info directories in order to get rid of potential rebuild when switching between release and release-with-debug-info.

[jonnenauha]

Well here are comparisons for you. I don't have all things currently here that we ship in releases, I only compare what I have in both.

                 Release    RelWithDebInfo
/plugins/*.dll   14,4 mb    32,2 mb  (Tundra/Meshmoon plugins)
/*.dll/*.exe     84,0 mb    94,8 mb  (deps + TundraCore + exe:s)

You can see with this clearly that the optimization flags make a big difference. The difference is not big on the dependencies, but is over 50% bigger in our DLLs. Only proving my point that this is NOT insignificant. If you would add the normal debug info to Qt DLLs you are certainly looking at +20-30 megs. This how big the dependencies diff would be if we would employ same flags to all our deps too? Right not we many times build Release and Debug, no RelWithDebInfo at all, so this kind of skews the dependency comparison. They are mostly the exact same DLLs.

Your assumption of 10-20 meg overhead for the total release is way off, I'm not sure if you though you could also add Qt debug DLLs into that 20 megs? :) We get 20 megs from ~70% of the shipped Tundra plugin/module DLLs. (again I did not have all of them built).

I really did look at the sizes quite a lot when doing the optimization flags and I build our codebase optimized, normal release and relwithdebinfo all the time. I didn't just pull this stuff up my ass, its observations during preparations of releases and what makes sense :)

Can we now drop the "no significant size overhead" argument? :) I can surely ship +30 megs once the automated crash reporting is done, but not before it, its dead space.

[Stinkfist0]

Assuming that we use the OPTIMIZED_RELEASE build config for RelWithDebInfo Tundra/Rocket (have to double check that these options do not remove the possibility to use the debug info) there should be no difference in the total Tundra plugin sizes as seen in my comparison of the 23 common plugins between Rocket release and Rocket nightly.

BTW Updated the issue title and description a bit.

[jonnenauha]

ugh... you are free to build whatever on your local machine and bloat your DLLs. I've said enough on this topic.