Re: [boost] CMake - one more time

Subject: Re: [boost] CMake - one more time
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-04-23 12:47:58

> On Apr 23, 2016, at 8:34 AM, Raffi Enficiaud <raffi.enficiaud_at_[hidden]> wrote:
> 
> 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.

It doesn’t offer the granularity. The granularity comes from the modularity of libraries. If that doesn’t give enough granularity then most likely a library needs to be split up into smaller libraries.

> 
>>> 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.

And because it is a practice in boost doesn’t mean it is good practice.

> 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”).

I understand testing all variants. I don’t see why one library is providing that many library targets.

> 
> 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.

That is not true. The object library was created to handle optimizing building both static/shared variants.

> 
>>> In my experience I end up using different linking modes for different
>>> libraries which are in the same
>>> repository.
>> 
>> Sounds way too complicated.
> 
> Why?

When linking static and shared libraries together it can lead to a lot of complicated problems. You have to make sure the static code is built PIC depending on how it needs to be linked together. 

> 
>>> 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.

Yes, but a cmake module could take care of that under the hood.

> But the build variants are just one aspect of the problem, there are many others.

Other build variants require building again, the static/shared variant is the only one that offers an optimization.

> 
> Raffi
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost