On 7/30/2017 3:12 PM, Louis Dionne via Boost wrote:
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.
I do not understand two issues: 1) Why does find_package have to be used for header-only libraries at all ? Or what does it buy you in CMake terms for header-only libraries ? 2) Why is it assumed that individual Boost libraries can be shipped when there is no current or proposed version control to insure that some individual Boost library shipped by itself will actually work properly with some other individual Boost library shipped by itself that is its dependent ? Is there an encompassing solution in CMake to this problem ?
Louis