On 6/8/21 2:58 AM, 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.
(b2 does this "right" by having static/shared as a build feature, and propagating it automatically. No need to split your targets by hand.)
Swimming upstream is sometimes justified when it results in something objectively better than the accepted CMake way, but I don't believe that's the case here, so BUILD_SHARED_LIBS will have to do. (Similarly, I tried to do something b2-like with the tests, but at the end reverting to the way CMake wants to do things proved better.)
Getting back to Boost.Test, I've duplicated the targets with an included_ prefix:
https://github.com/boostorg/test/commit/bce2d24c8b32f47f0403766fe4fee3e2e93a...
Not to start a bikeshedding argument, but maybe a more generic naming scheme would be preferable? I'm thinking something like Boost::x names the default config, Boost::x::header_only means header-only variant, Boost::x::static means static library, and so on. This makes it possible to add more configurations in the future, including the library-specific ones, if needed.