Peter Dimov wrote:
But I think that Paul's insistence to support the cget workflow, for which nobody at the moment cares but him,
Agree, I personally don't care about cget (sorry Paul). I think it's a neat tool, but I'm not using and I don't think we should predicate any technical decision on the ease of interoperation with cget. HOWEVER...
is making things more complicated and error-prone than they could be.
I don't think that's the case, see below.
(The cget workflow is the ability to build and install Boost libraries one by one, independently of one another, without a superproject; this requires them to refer to one another with find_package.)
This is not specific to the cget workflow. Generally speaking, if we want to be able to consider libraries as individual entities (or "packages"), the recommended way of resolving dependencies is to use `find_package`. This is really neat, as it means we could e.g. ship individual libraries using Conan. That's the big modularization that some of us have been talking about (and many users want) just at our fingertips, and we only need to use `find_package` instead of leaving the dependencies be implicit. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-tests-with-cmake-tp4697568p4697605.... Sent from the Boost - Dev mailing list archive at Nabble.com.