Le 23/04/16 à 14:00, Paul Fultz II a écrit :
On Apr 23, 2016, at 5:40 AM, Klaim - Joël Lamotte
wrote:
<snip>
This is not necessary at all. Cmake provides the `BUILD_SHARED_LIBS` variable that can be set to do this same purpose:
https://cmake.org/cmake/help/v3.5/variable/BUILD_SHARED_LIBS.html
It forces all the targets defined after setting it to use the defined linking mode.
There is only one library target.
I agree with Joël (please excuse me if it is "Klaim - Joël"). The "BUILD_SHARED_LIBS" is a global that is applied by default to all targets. It does not offer the granularity we are talking about here.
Most repositories of tools (outside boost at least) provide several libraries or executables targets.
I don’t see why a library would build more than one library, and it wouldn’t make sense to change the linking mode for an executable(that is if you build the library static then the executable will need to link against the static version of the library, since its the only one available).
The fact that you do not see why does not mean that this is not a practice in boost. We have that in boost.test for instance: we need to test several variants. Also the fact that you do not use this feature is also because of the limitation of cmake (means "if cmake was able to do that, you would maybe see a good reason to do that"). This is not covered by CMake, *by design*, while it is in BJam, *by design*. The *by design* is important here: all attempts to cover the design limitations needs an effort.
In my experience I end up using different linking modes for different libraries which are in the same repository.
Sounds way too complicated.
Why?
Or the target still need to be built and distributed in several linking modes.
Yes, but you can just build it twice.
I believe you are missing some important element: each target may be build in eg. different link type, say "M" (static, shared, whatever). Say you have N targets: we have M^N combinations of variants if we take the full set of targets. Of course, I can build it M^N (worst case) times, with the same order of switches in the CMakeLists.txt ...
Therefore, I can never use BUILD_SHARED_LIBS because it is not fined-grained enough.
In my opinion, having multiple targets, one for each linking mode that make sense for the library usage, works better.
I don’t see how that makes sense at all. A library could provide a flag to build both as an optimization, otherwise it should just fall back on the default.
Could? Should? CMake did not enforce that at least, so it is not up to you to decide neither. But the build variants are just one aspect of the problem, there are many others. Raffi