On Mon, Apr 22, 2013 at 01:04:30PM +0200, Stephan Bergmann wrote:
On 04/17/2013 04:45 PM, Bjoern Michaelsen wrote:
On Wed, Apr 17, 2013 at 04:13:15PM +0200, Stephan Bergmann wrote:
What good is the intermediate move? That is, was there at least one
situation in which it would have helped your debugging if an
existing RTL_LOGFILE_* call had been behaving like SAL_LOG?
Yes, there had been: I was trying to wrap my haed around the
observer-pattern-gone-bad of vcl-callbacks going into
framework/uielement/menubarmanager.cxx to see if there is something going wrong
with the order of execution. RTL_LOGFILE provides some helpful ad-hoc hints
there without manually setting bazillion breakpoints or adding SAL_INFOs there.
I think Tor's comment is to the point. Ultimately, we'll want
SAL_WARN/SAL_INFO enabled in more builds, so we shouldn't get too
carried away with adding too many SAL_INFOs for tracing purposes.
I can see your point for SAL_WARN, but not really for SAL_INFO. I cant think of
a scenario where a buildwide enabling of SAL_INFO makes much sense, however I
can see much use in enabling it for one lib/module/whatever, and for that it
doesnt have to be too restrained.
Best,
Bjoern
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.