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.