Re: [boost] Boost tests with cmake

Subject: Re: [boost] Boost tests with cmake
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-30 19:57:42

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