Re: forward RTL_CONTEXT_foo logging to SAL_INFO in default debugging

On 04/22/2013 01:17 PM, Bjoern Michaelsen wrote:
> 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.

I'm not sure we're talking about the same thing here.  With "enabled" I 
meant having SAL_WARN/SAL_INFO expand to actual code (instead of having 
the compiler optimize it away).  Whether that code then also does some 
logging depends on further constraints (SAL_LOG env var), but my point 
was that the code itself does incur a certain (small) runtime cost.

Stephan