On 08.06.21 01:58, 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...
Thanks, it looks good to me and if it works for Edward, then all good :) BUILD_SHARED_LIBS is a global property inherited by all targets, with the drawback of not being able to explain all desirable configurations (# exponential in the number of targets). One example where it is not working: I need to run the unit tests of Boost.Test with shared, static and header only, so those 3 targets must exist. But this is not an isolated usage: as a project grow, it is sometimes needed that a specific lib exists in both shared and static variant. In any case, it is always possible (later, if needed) to define the shared/static explicitly and make an alias on the target that mimics BUILD_SHARED_LIBS. I have to thank Peter and all other boosters that participated to this effort. On a side note: I believe the "democratic" way of doing it does not work inside the current boost setup, and yield endless discussions not producing any artifacts. OTOH, the person doing that should have enough established authority & being respected within Boost for doing such a job. Peter has this, I do not. Coming back to Boost.Test, Edward + Peter: your call. Raffi