|
Boost : |
Subject: Re: [boost] CMake - one more time
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2016-04-23 15:31:51
On 23 April 2016 at 14:00, Paul Fultz II <pfultz2_at_[hidden]> wrote:
>
> > On Apr 23, 2016, at 5:40 AM, Klaim - Joël Lamotte <mjklaim_at_[hidden]>
> wrote:
> >
> > On 23 April 2016 at 02:36, Paul Fultz II <pfultz2_at_[hidden]> wrote:
> >
> >>
> >>> On Apr 22, 2016, at 5:41 PM, Robert Ramey <ramey_at_[hidden]> 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
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk