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 _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem