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