On 05/22/2012 04:02 PM, Lubos Lunak wrote:
On Tuesday 22 of May 2012, Stephan Bergmann wrote: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).Uhm? If that is the case, then no wonder people get confused, since this means that dbgutil is a superset of debug, except not quite. I've already asked Michael, so I'm going to ask you too: What is your idea about what these options do?
common subset of what --enable-debug and --enable-dbgutil do: enable various assertions, warnings, etc. (technically, both enable OSL_DEBUG_LEVEL > 0 and disable NDEBUG, for example)
what --enable-debug does in addition: settings that aid in step-through debugging (like -O0, -fno-inline)
what --enable-dbgutil does in addition: enable additional assertions, warnings, etc. that are binary incompatible
Stephan