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

[Stephan Bergmann]

On 05/22/2012 03:19 PM, Lubos Lunak wrote:
> On Monday 21 of May 2012, Stephan Bergmann wrote:
>> 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).
>
>   But --enable-debug also enables asserts, logging and similar functionality
> that should be rather useful for developer builds, doesn't it?

But --enable-dbgutil enables that as well (and more of it).

>> Turning this around:  What is it that you find problematic with
>> --enable-dbgutil not affecting the default -O2?
>
>   I'm not strongly opposed to it, it just doesn't make much sense to me that
> way. I see --enable-dbgutil as another, higher, level of --enable-debug, in
> fact I wonder why it is not simply something like --enable-debug=full. So if
> you insist, I don't mind that much, but I still don't understand why anyone
> would want dbgutil without debug (although, on the other hand, dbgutil not
> affecting e.g. -O2 would not matter much because of this anyway).

So, case closed?  Everybody is more or less happy with the status quo of 
--enable-dbgutil not implicitly affecting default -O2, as far as I 
understand.

Stephan