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

Alexander Neundorf neundorf at kde.org
Fri Apr 24 18:47:14 BST 2009

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.

We could provide that variable as an option, set by default to FALSE, and as 
long as a library is in such a state you skip the SHARED/STATIC keyword.
So it will be built for everybody as a static lib, only for the developers 
which know what they are doing they can turn this to TRUE, and they will get 
a shared lib, which will make their development life easier.
If this is to easy we could also add a keyword "EXPERIMENTAL" or "UNSTABLE" 
additionally to SHARED/STATIC/MODULE, which would then react not to 
BUILD_SHARED_LIBS, but e.g. to 

For the stuff which links to that library it just depends on which library is 
found during at cmake time, if the shared one is found this one will be used, 
if the static one is found the static one will be used.


More information about the kde-core-devel mailing list