Consolidating debugging levels (via Easy Hacks)

[Markus Mohrhard]

Hey,

On Tue, May 26, 2015 at 11:52 AM, Bjoern Michaelsen <
bjoern.michaelsen at canonical.com> wrote:

> Hi,
>
> we still have multiple othogonal and confusing debug levels in LibreOffice,
> that can interact in funky ways, the most common ones being
> OSL_DEBUG_LEVEL and
> DBG_UTL.
>
> I'd like to propose to consolidate these into _one_ general debug level
> with no
> funky interaction. As such, I'd like to work towards the following
> (ideally via
> Easy Hacks):
> - Disable all current code that is enabled by OSL_DEBUG_LEVEL > 1 by
> enclosing
>   them in "#if 0" (or alternatively: triggered by an explicit define for
> the
>   area of code e.g. say DEBUG_SW_LAYOUT)
> - Once that is done, make OSL_DEBUG_LEVEL = 2 and DBG_UTL equivalent.
>
> The goal is to have three general debug levels on one axis:
> - level 0: release build
> - level 1: additional debug code, but binary compatible with level 0 (same
>            library interface, comparable to OSL_DEBUG_LEVEL = 1)
> - level 2: additional debug code, binary incompatible with level 1 and 2
> (aka DBG_UTL)
>
> Everything beyond that should either be "#if 0"'ed or "#ifdef
> DEBUG_${MODULE}_${AREA}".
>
> Opinions? If there are no objections, I would file Easy Hacks for that.
>
>

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)

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.

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.

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.

Regards,
Markis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20150527/8926089c/attachment.html>