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/21/2012 05:10 PM, Lubos Lunak wrote:
> On Friday 18 of May 2012, Stephan Bergmann wrote:
> > 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.

I rarely use a debugger to step through code, so I prefer to avoid the 
--enable-debug settings that, AFAIU, are mainly there to aid in 
step-through debugging, but nevertheless cause potential deviation from 
a production build (like -O0, -fno-inline).

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

OK, tracing gb_LinkTarget__get_{c,objc,cxx,objcxx}flags 
(solenv/gbuild/LinkTarget.mk), for a --disable-debug build these 
environment variables indeed seem to only affect -O switches.  (From 
Michael Stahl's explanations, I would have assumed they would at least 
also affect -g switches, however.)  But looking at that code also shows 
that explicitly setting CFLAGS and CXXFLAGS would give potentially 
unexpected results -- one needs to set OBJCFLAGS and OBJCXXFLAGS as well 
-- which brings me back to my point of reliability.

Turning this around:  What is it that you find problematic with 
--enable-dbgutil not affecting the default -O2?

Stephan