Re: --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)

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

Stephan