LIBRARY_TYPE in ECMQtFramework.cmake

[Alexander Neundorf]

On Monday 07 May 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Hi,
> > 
> > in ECMQtFramework.cmake there is the line
> > 
> > set(LIBRARY_TYPE SHARED)
> > 
> > which is used later on in the libraries e.g. like this:
> > 
> > add_library(itemmodels ${LIBRARY_TYPE} ${itemmodels_SRCS})
> > 
> > What is this good for ?
> > It is not in the cache, so it is hardcoded.
> 
> The intention was to fix that at some point. I never looked into the
> details, but wanted to keep in parametrizable (as it is in KDE4 I think).

In KDE4 it is usually hardcoded to SHARED.
The assumption was that KDE generally works a lot with plugins etc. so we want 
shared libs in most cases.

It may be a bit different with KDE frameworks.
Small libraries like itemmodels can make sense also as static libs.
Ok, not that much.
I mean, if some proprietary software (which are a good candidate for linking 
statically, since they often don't want to rely on system shared libs) would 
want to use itemmodels, it basically would have to link dynamically due to 
LGPL (yes, in theory you can link statically to a LGPL library, but I don't 
think anybody wants that).

I'd actively ignore Win CE for this. I think Win CE is unsuited to run KDE, at 
least as a whole.

> > To switch between shared and static libs, there is the cmake variable
> > BUILD_SHARED_LIBS, which can be set to TRUE or FALSE depending on what is
> > wanted (defaults to not set i.e. to static libs).
> > 
> > So, is the intent to have it switchable (then BUILD_SHARED_LIBS should be
> > preset to TRUE in the cache),
> 
> Right. Cool.
> 
> > or is the reason to hardcode it to SHARED ?
> > 
> > Beside that, do we actually (want to) support building static libs ?
> 
> Probably not 'support'. I'm sure we can allow it to be possible without too
> much effort or without calling it supported.
> 
> But indeed I don't think we need this LIBRARY_TYPE thing.

Ok. So I'll remove it and add BUILD_SHARED_LIBS = TRUE to the cache.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20120508/e8f1147e/attachment.html>