Re: [boost] CMake - one more time

On 23 April 2016 at 14:00, Paul Fultz II wrote:

...

On Apr 23, 2016, at 5:40 AM, Klaim - Joël Lamotte wrote:

On 23 April 2016 at 02:36, Paul Fultz II wrote:

...

...

On Apr 22, 2016, at 5:41 PM, Robert Ramey wrote:

On 4/22/16 2:56 PM, Raffi Enficiaud wrote:

...

Certainly, CMake can do everything with the appropriate effort. But so far, although I am a CMake user, I do not know how to do this:

- having the same target name with different target properties: like set(PROJECT_SRC ....) add_library(myproject SHARED ${PROJECT_SRC}) add_library(myproject STATIC ${PROJECT_SRC})

how do you do that? how do you refer to the appropriate variant?

I know it's beside the point of your post, but I can't resist.

I do this in the following way.

a) I set up a cached boolean variable USE_STATIC b) I use the CMake script

if(USE_STATIC) add_library(myproject STATIC ${PROJECT_SRC}) else() add_library(myproject SHARED ${PROJECT_SRC}) elseif()

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.

...

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

I said one repository, several libraries. Of course I was talking about the linking mode of the several libraries. If you think about boost libraries, then only one library is in one repository indeed. But if you build all boost once, then you still have to set a variable for each library you want static or dynamic. So it's still not fined grained enough.

...

In my experience I end up using different linking modes for different libraries which are in the same repository.

Sounds way too complicated.

Yep, tha'ts the problem with real world project. Sometime you don't have a choice.

...

Or the target still need to be built and distributed in several linking modes.

Yes, but you can just build it twice.

That is indeed an alternative. Which produce a lot of data for no good reasons, but still an alternative.

...

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.

If you don't want to have to configure the library several times, then it's easier to configure once and then make have your target link to the static or dynamic target at will. It makes things very simple in particular with projects that need to evolve quickly. Anyway, what I am saying is that maybe your experience don't match all the actual use case of projects, which leads to false assumptions about what is enough and what is not. On this particular point, I totally disagree that BUILD_SHARED_LIBS is useful. It's like a hack to not help solve the issue.

...

_______________________________________________ Unsubscribe & other changes:

http://lists.boost.org/mailman/listinfo.cgi/boost

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