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 my noise.