Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


Hey,

On Tue, May 26, 2015 at 11:52 AM, Bjoern Michaelsen <
bjoern.michaelsen@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.