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

[Aaron J. Seigo]

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?

i don't mind changing the CMakeLists.txt in knotificationareaitem (that's just 
one file :) but i do mind changing N different apps scattered all over kde's 
svn.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090424/0ba0a96b/attachment.sig>