RFC v2: adding a temporary, non-BC gauranteed, 'private' library

[Alexander Neundorf]

On Friday 24 April 2009, Aaron J. Seigo wrote:
> On Friday 24 April 2009, Alexander Neundorf wrote:
> > On Friday 24 April 2009, Aaron J. Seigo wrote:
> > > On Friday 24 April 2009, Alexander Neundorf wrote:
> > > > Would it be an option to make it optional whether the lib is built
> > > > shared or static, making static the default and for releases, and you
> > > > as a developer could switch it to shared so you get the advantages
> > > > you mention ?
> > >
> > > is there a CMake directive along the lines of
> > > link_static_or_dynamic_depending_on_which_is_available?
> > >
> > > i don't realistically see us running around prior to release and
> > > changing all possibly affected cmake files.
> >
> > If you skip the SHARED/STATIC/MODULE in
> >
> > (kde4_)add_library(foo (SHARED|STATIC|MODULE) ${srcs} )
> >
> > then it depends on the value of the BUILD_SHARED_LIBS variable whether it
> > will be built as a shared or a static one.
>
> no, i meant the other way around. in target_add_libraries, if i put
> knotificationareitem in there is it smart enough to know when to use static
> vs dynamic linkage depending on what's available on the system?

If there are both, the static and shared one, I'm not completely sure which 
one will be chosen, if only one of both types is installed and found, it is 
completely transparent, no changes in the CMakeLists.txt necessary.
Does that answer your question ?

Alex