--enable-debug vs --enable-symbols (Re: [Libreoffice-commits] .: 12 commits - config_host.mk.in configure.in filter/source oox/source sal/inc sc/source solenv/gbuild toolkit/source xmlhelp/source)

[Lubos Lunak]

On Wednesday 16 of May 2012, Stephan Bergmann wrote:
> On 05/16/2012 04:07 PM, Lubos Lunak wrote:
> >   Given that those differences you mention should be either irrelevant in
> > practice or compiler bugs, even I, having rather fast build system, do
> > not see -O2 worth using.
>
> ...yes, I mainly alluded to compiler bugs.  But even those need to be
> found somehow...
>
> Then again, my views might indeed be over-conservative here.

 That makes you a special case :). It's ok to let you do what you want to do, 
but you're not the target to optimize for.

> >> Re "unless explicitly told so"---how is one supposed to tell the build
> >> system?
> >
> >   I'm not the build expert here :). You can pass -O2 explicitly to
> > CXXFLAGS, at least. It's rather a corner case to build with
> > --enable-debug and -O2 at the same time.
>
> I think a root problem for confusion still is that we have those various
> configure switches that lead to specific compiler switches in opaque
> ways.

 I don't see why it should be so confusing:
- non-debug/dbgutils (i.e. also the default) -> -O2
- symbols -> -g  (probably even -g1, if this is actually meant for release 
builds with debug info sufficient mainly for backtraces)
- debug/dbgutils -> -g, making sure it overrides -g1 from symbols
- explicit C(XX)FLAGS overrides anything

> How do other projects handle that?  Never automatically add any 
> -g or -O switches, so requiring the user to always explicitly specify
> CFLAGS/CXXFLAGS if he wants anything other than the compiler's default
> -O0?

 AFAIK most projects default to release build and provide a way to switch to 
developer build. IIRC autotools by default uses -O2 as C(XX)FLAGS if it's not 
set, most autotools-based projects have some kind of --enable-debug, and 
CMake has built-in support for build type (debug,release,relwithdebinfo).

-- 
 Lubos Lunak
 l.lunak at suse.cz