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:
> > 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 
KDE4_BUILD_UNSTABLE_LIBS_AS_SHARED_LIBS_BUT_MAY_EAT_YOUR_PETS to make it more 
explicit.

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.

Alex