--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 Friday 18 of May 2012, Stephan Bergmann wrote:
> On 05/18/2012 04:05 PM, Lubos Lunak wrote:
> > On Friday 18 of May 2012, Stephan Bergmann wrote:
> >> On 05/16/2012 05:01 PM, Lubos Lunak wrote:
> >>> - 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
> >>
> >> ...and, as something of a special case, no -O... at all (instead of the
> >> default -O2) for sc under --enable-debug=-sc/?
> >
> >   Yes, but I don't think it's special. The rule, missing in the list
> > above, would be 'debug/dbgutils ->  optimizations disabled'. So as soon
> > as there's --enable-debug, nothing would get -O2, regardless of symbols.
> >
> >   That's actually one more reason why I think -g should be primarily
> > controlled by --enable-symbols and not --enable-debug.
>
> Ah, you wanted --enable-dbgutil to disable -O2, the same way that
> --enable-debug does.  Had missed that point.  Hm, as I said, I prefer my
> --enable-dbgutil --disable-debug builds to be -O2.

 What is the point of that combination? As far as I can tell --enable-dbgutil 
is like --enable-debug but for changes that are BIC, so only dbgutil without 
debug does not make much sense to me.

> So if we change 
> --enable-dbgutil to imply -O0, I'd like to see that changeset also offer
> a reliable way to get back -O2.  (And I'm not sure having to set
> C(XX)FLAGS can be considered reliable enough, given that pre-set
> C(XX)FLAGS impact more decisions in our build system than just -O2 vs.
> -O0.  But maybe I'm asking for too much.)

 What other (relevant) decisions should be affected by that?

-- 
 Lubos Lunak
 l.lunak at suse.cz