Re: [boost] Recent changes in Boost policies

Subject: Re: [boost] Recent changes in Boost policies
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-05-30 14:32:30

On Saturday 30 May 2015 16:29:07 Niall Douglas wrote:
> On 30 May 2015 at 17:57, Peter Dimov wrote:
> 
> > (Bringing in Boost.Test as a dependency brings in the world.) But if
> > you're using the ability to run the library's tests as an indication of
> > whether bpm has worked, then yes, you'll find that it hasn't
> > worked for some.
> 
> If the sole roadblock remaining to a bpm based fully modular Boost
> release is Boost.Test, then I think none of us at that meeting were
> aware of that.
> 
> And if that is indeed the case, then that puts a *very* different
> spin on things indeed, and you should tell the Boost steering
> committee via that mailing list as that has enormous relevance to
> their deliberations.
> 
> I'll put this another way round: most libraries using Boost.Test use
> like 2% of the functionality. A quick and dirty emulation of
> Boost.Test like the one in APIBind could replace the Boost.Test
> dependency for almost all libraries in Boost with relatively little
> work.
> 
> In other words, if I have understood you right, Boost could be a
> fully modular distro as early as end of this year if Boost were to
> award a small grant for the grunt work involved.

Boost.Test is only manifestation of the problem. As has been said in multiple 
discussions on this list, there are generally three sets of dependencies: the 
dependencies needed to use the library, to build it and to test it (well, 
there is fourth also: to build its docs, but we'll ignore it for now). The 
three sets can be very different. If I'm not mistaken (let Peter correct me if 
I am), bpm takes care of the first two sets without distinguishing between 
them and ignores the third one because it typically adds many more 
dependencies that aren't needed if you don't intend to run the library tests.

Trying to emulate Boost.Test is not the solution (and we already have 
lightweight_test.hpp for that). I think, bpm has to distinguish between the 
three sets of dependencies and let the user decide what he wants to install.