--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 03:09 PM, Lubos Lunak wrote:
> >   Now --enable-debug=-sc/ means that sc/ is built without -g and with
> > -O2. In other words, the compiler spends extra time working on code I
> > don't care about at all. There was a reason why OPT flags was empty in
> > --enable-debug build - as soon as I do a developer build, I don't want
> > the compiler to optimize any code, anywhere, unless explicitly told so.
>
> As code is traditionally known to occasionally behave differently for
> different -O levels, I'm fine with my personal builds by default using
> the same -O2 as production builds.

 That's probably because you have something really fast to build LO on? 
Building with -O2 usually makes the build several times slower than without. 
It should be a huge difference for people who hack on whatever they have as 
their home machine.

 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.

> 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.

> (Or am I confusing what you want to say, and the part of your paragraph
> starting "as soon as" shall only apply in the context of explicit
> --enable-debug=-sc/?  Likely.)

 The part starting with "as soon as" is a standalone thought. If somebody does 
a developer build, there are not many good reasons why -O2 should be used - 
it takes noticably more time and it makes debugging miserable. I can't think 
of anything else than final builds and profiling as a good non-corner-case 
reason for -O2.

-- 
 Lubos Lunak
 l.lunak at suse.cz