[Patch] introduce new cmake var KDE4_LIB_DESTINATION

[Alexander Neundorf]

Hi,

On Thursday 14 February 2008, Christian Ehrlicher wrote:
> Hi,
>
> following the discussion in 'Re: Getting rid of the LIB_INSTALL_DIR hack
> on windows' (http://lists.kde.org/?t=120015619300001&r=1&w=2) I created
> a patch which introduces a new var KDE4_LIB_DESTINATION.
>
> On Linux it's simply LIB_INSTALL_PREFIX:
> _set_fancy(KDE4_LIB_DESTINATION ${LIB_INSTALL_DIR})

I think the variable shouldn't have the KDE4_ prefix, since this is used for 
the variables which are "imported" from the installed kdelibs (i.e. which 
show the install location of the installed kdelibs), which can be different 
from the install locations of the current project. 
So we need another name.

> and on windows it's
> set(KDE4_LIB_DESTINATION RUNTIME DESTINATION "bin"
>                           LIBRARY DESTINATION "lib${LIB_SUFFIX}"
>                           ARCHIVE DESTINATION "lib${LIB_SUFFIX}"  )
>
>
> The reason why we need a special var instead using LIB_INSTALL_DIR is
> that we currently can't use LIB_INSTALL_DIR somewhere outside
> install(TARGET ...) but sometimes we simply need it :)

Is this the only reason ?
Maybe we could also do it the other way, keep LIB_INSTALL_DIR as it is and add 
LIB_INSTALL_PREFIX (or something like that), which would contain really only 
that one directory on all platforms.
This would be less work I think, because all the install(TARGETS ... ) (except 
the problematic ones) could stay unchanged.

I'm still really undecided.
You know, if we keep using the basically regular syntax using the 
LIB_INSTALL_DIR hack (on windows), somebody who knows cmake will just see 
what it does (except for windows). If he doesn't already know cmake, he can 
learn from that for his own projects without having to use the KDE4 cmake 
macros. This is a significant feature, which I really value.

Next option:
We could also add 
set(INSTALL_TARGET_DEFAULT_ARGUMENTS RUNTIME DESTINATION bin COMPONENT User
                                     LIBRARY DESTINATION lib COMPONENT User
                                     ARCHIVE DESTINATION lib COMPONENT Devel )

and then do
install(TARGETS konsole kdecore kdeui ${INSTALL_TARGETS_DEFAULT_ARGUMENTS})

Later on this could be extended once we require (or can optionally use, not 
sure about that) CMake 2.6 which supports library frameworks on OSX, they 
need even more locations.

Next option:
Once we _require_ CMake 2.6.x (so maybe for KDE 4.2), we could use the 
framework feature of cmake for all libraries in KDE, and I could add the 
feature to cmake so that the install locations could be initialized from 
target properties of that target. Setting these properties could be done in 
KDE4_ADD_EXECUTABLE/LIBRARY/...()
Then the install command would look something like:

install(TARGETS konsole kdecore kdeui USE_TARGET_PROPERTIES)

We can also keep in mind that KDE 4.0 hasn't been released on Windows, so we 
don't have to keep compatibility there yet. I.e. if somebody today relies on 
the fact that LIB_INSTALL_DIR contains all three locations on Windows, we 
still can break that. We just have to ensure that 
install(TARGETS kdecore DESTINATION ${LIB_INSTALL_DIR})
stays working on UNIX (OSX excluded, also not officially released yet).

Opinions ?

Alex