sbergman at redhat.com
Tue Aug 7 09:47:10 PDT 2012
On 08/07/2012 04:03 PM, Bjoern Michaelsen wrote:
> Just like Michael and Kohei, I dont use dbgutil and find it a flawed design
> anyway. But you dont need enable-dbgutil(*), a simple debug=T plus SAL_LOG=+WARN
> will do.
> (*) can we kill/merge that already? the only remaining valid reason for it is a
> debug stl implementation -- but that should be coupled with binary incompatible
> crap we do in our code.
I'm in favor of closing the gap between --enable-dbgutil and
--disable-dbgutil builds as much as possible, by having useful dbgutil
stuff (like enabling SAL_INFO/SAL_WARN, disabling NDEBUG) always on. I
do not know what "crap" --enable-dbgutil currently enables (at least I
know none in the areas of the code I feel familiar with), but any such
annoyances might probably benefit from clean up?
However, I wouldn't instead merge --enable-dbgutil with --enable-debug
(if that's what you are proposing), as --enable-debug's -O0 IMO has
potential for just as much deviation in behavior as has any
--enable-dbgutil. That way, proponents of "run sth as close to a
customer's build as possible" (which indeed is a good approach IMO)
would remain stuck with none of --enable-dbgutil's benefits.
(Btw, an explicit SAL_LOG=+WARN is unnecessary, as that's the default
being used for an unset SAL_LOG anyway.)
More information about the LibreOffice