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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
