From: Edward Diener (eldiener_at_[hidden])
Date: 2021-06-08 04:53:59
On 6/7/2021 7:58 PM, Peter Dimov via Boost wrote:
> Raffi Enficiaud wrote:
>> I have not looked at the recent developments for CMake in Boost. If the
>> CMakeLists.txt I developed (under build/) is still there, it contained 2
>> targets: one for static and one for shared. Those were having different and
>> explicit names.
> I decided to not do this and instead use the "normal" CMake way of relying
> on BUILD_SHARED_LIBS.
> It causes problems in the more complicated cases where a compiled Boost::X
> links to header-only Boost::Y which links to a compiled Boost::Z. Client code
> can choose to link explicitly to Boost::static_X, and if X used Z directly, it could
> link to Boost::static_Z, but it doesn't. And requiring all header-only libraries
> to also provide triplicate targets so that static/shared-ness can be propagated
> correctly is (I think) infeasible. So X links to Boost::Y, and Y has to choose
> whether to link to the static or shared Z, but it doesn't know how.
I do not know CMake, so maybe my comment is irrelevant, but it seems
natural to me that a header-only library would always choose to use some
other dependent library as header-only, even when that other library had
static or shared variants. In other words I applaud the decision of
Boost.Test to provide a header-only variant and can not even begin to
process the fact that CMake can not deal with Boost.Test as a
header-only library, if that is indeed the case.
If you are saying that the use of Boost.Test within Boost's creation of
CMakeLists.txt for its libraries can never be as a header-only only
library, please reconsider. If you are not saying that I apologize for
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk