<div dir="ltr">Hey,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 11:52 AM, Bjoern Michaelsen <span dir="ltr"><<a href="mailto:bjoern.michaelsen@canonical.com" target="_blank">bjoern.michaelsen@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
we still have multiple othogonal and confusing debug levels in LibreOffice,<br>
that can interact in funky ways, the most common ones being OSL_DEBUG_LEVEL and<br>
DBG_UTL.<br>
<br>
I'd like to propose to consolidate these into _one_ general debug level with no<br>
funky interaction. As such, I'd like to work towards the following (ideally via<br>
Easy Hacks):<br>
- Disable all current code that is enabled by OSL_DEBUG_LEVEL > 1 by enclosing<br>
  them in "#if 0" (or alternatively: triggered by an explicit define for the<br>
  area of code e.g. say DEBUG_SW_LAYOUT)<br>
- Once that is done, make OSL_DEBUG_LEVEL = 2 and DBG_UTL equivalent.<br>
<br>
The goal is to have three general debug levels on one axis:<br>
- level 0: release build<br>
- level 1: additional debug code, but binary compatible with level 0 (same<br>
           library interface, comparable to OSL_DEBUG_LEVEL = 1)<br>
- level 2: additional debug code, binary incompatible with level 1 and 2 (aka DBG_UTL)<br>
<br>
Everything beyond that should either be "#if 0"'ed or "#ifdef DEBUG_${MODULE}_${AREA}".<br>
<br>
Opinions? If there are no objections, I would file Easy Hacks for that.<br>
<br></blockquote></div><br><br></div><div class="gmail_extra">So just some comments from someone who uses dbgutil a lot and is quite annoyed by unrelated log output. (actually I just removed a ton of log output in dbgutil builds that should have either be hidden behind a OSL_DEBUG_LEVEL or behind SAL_INFO)<br><br></div><div class="gmail_extra">IMHO dbgutil and the log levels should be orthogonal. dbgutil is a mode where we include binary incompatible code and can enable additional asserts that should not be included in a release build. dbgutil is something that is generally useful for developers. However log output should be limited to what is really essential by default. E.g. enabling SAL_WARN with dbgutil is not too bad as long as SAL_WARN is used responsibly.<br><br></div><div class="gmail_extra">So to summarize it I think a solution that makes the log output orthogonal to the assert and binary incompatibility is necessary. If you provide that orthogonality as build option (current solution) or runtime option (the SAL_INFO way) is not that important.<br><br></div><div class="gmail_extra">Feel free to ignore my comments. It does not affect me anymore and I just wanted to share the opinion of someone who is not a fan of global log output but used dbgutil a lot.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,<br></div><div class="gmail_extra">Markis<br></div><div class="gmail_extra"><br></div></div>