From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2021-06-08 07:33:42
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:
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
I have to thank Peter and all other boosters that participated to this
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk