Boost logo

Boost :

Subject: Re: [boost] CMake - one more time
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2016-04-23 09:34:04


Le 23/04/16 à 14:00, Paul Fultz II a écrit :
>
>> On Apr 23, 2016, at 5:40 AM, Klaim - Joël Lamotte <mjklaim_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk