-O2 in Debug build?

[Andreas Pakulat]

On 18.07.08 17:55:50, Thiago Macieira wrote:
> Alexander Neundorf wrote:
> >On Friday 18 July 2008, Andreas Pakulat wrote:
> >> Hi,
> >>
> >> Whats the reasoning behind using -O2 in the Debug CXX flags? A debug
> >> build shouldn't use _any_ optimizations IMHO.
> >
> >I think there were lengthy discussion about the flags for the different
> > build types. I guess this was the result.
> >/me hasn't slept a lot this week, so I don't feel like searching for
> > this now
> 
> The reason is that we split the build types in (for gcc):
> 
> Release
> 	optimised for speed, qDebug/kDebug turned off, no debug symbols
> Release with debug info
> 	optimised for speed, debugging symbols on (-g)
> Debug
> 	optimised but debuggable, debugging on (-g)
> 	(-fno-reorder-blocks -fno-schedule-insns -fno-inline)
> DebugFull
> 	no optimisation, full debugging on (-g3)
> Profile
> 	DebugFull + -ftest-coverage -fprofile-arcs

Damn, actually I have a slight feeling I've asked this already. Any
objections against putting this information close to the gcc-version of
setting the flags. So neither I nor anybody else need to ask stupid
questions again?

> It is expected that the "Debug" build type be still debuggable with gdb 
> without going all over the place, but still produce better performance. 
> It's also important to note that gcc cannot detect all warning conditions 
> unless the optimiser is active.

Sigh, compilers ;)

> I'd say that "debug" is recommended for kdelibs for people developing KDE 
> applications, since oftentimes they may have to go into kdelibs 
> functions. Their own code should be build under debugfull while still in 
> development, but should be built a few times in release before a release.

Ok, I guess that means I can add "debugfull" to
CMAKE_CONFIGURATION_TYPES in FindKDE4Internal? Or does somebody have
objections against that.

Andreas

-- 
You will be Told about it Tomorrow.  Go Home and Prepare Thyself.