Re: [boost] [log] Boost.Log formal review

Subject: Re: [boost] [log] Boost.Log formal review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-03-13 10:38:00

On 03/12/2010 01:00 PM, Barend Gehrels wrote:
>
> However, what might happen is that if there is an attractive logging
> library, Boost library writers start to use it, of course. All libraries
> using the logging functionality will need compilation. I normally use
> only header only libraries from Boost (sometimes making an exception).
> So this scenario might cause me stopping using Boost... There are much
> more people using only header-only Boost headers.

I think, you're exaggerating things. I agree that linking with a library 
is a bit more complicated than including a header, but it's hardly a 
showstopper. If it is, you should really revise your build system, and 
it's not Boost's concern, IMHO.

> It might be even worse. If *existing* libraries will start using
> Boost.Log in an update (because it is really useful), existing project
> files and solutions will be broken.
>
> And finally for me the worst case scenario: if *existing *libraries
> *used in Boost.Geometry* will start using Boost.Log in an update, our
> Boost.Geometry library is broken and not header only anymore.

If you're speaking of libraries in the broader meaning than Boost, then 
I see no problem in using Boost.Log in them. In fact, I think Boost.Log 
is suited quite well for this scenario. That actually is also true for 
the compiled libraries in Boost.

As for header-only libraries, I think, the most reasonable solution 
would be to provide a configuration option for these libraries, so that 
the user is able to decide, whether he wants logging or not. After all, 
if the user already employs Boost.Log in his application, there's no 
downside if headers of Boost libraries also use Boost.Log to provide 
more information. If the user strives for header-onlyness, he would be 
able to remove references to Boost.Log.