On Tuesday 18 December 2012, Stephen Kelly wrote: > Alexander Neundorf wrote: > > On Thursday 29 November 2012, Stephen Kelly wrote: > >> Alexander Neundorf wrote: > >> > The code for creating a Config.cmake file is not trivial, but IMO also > >> > not boilerplate, and Stephen agreed in Berlin that this will have to > >> > be done individually be every project. This is the added > >> > threadweaverConfig.cmake.in and the call to > >> > configure_package_config_file() in the CMakeLists.txt. > > > > ... > > > >> 2) You are setting things that do not need to be set: > >> * Eg: kwidgetsaddons_INCLUDE_DIR, kwidgetsaddons_LIBRARY_DIR. > >> > >> The kwidgetsaddons_LIBRARY_DIR is not needed at all. That's the kind of > >> thing that you only need (and put in the cache) if you're writing a Find > > > > I was about to remove the LIBRARY_DIR variable, but... > > the user may want to use the Foo_LIBRARY_DIR variable for setting the > > RPATH of his own executables. > > Doesn't cmake have facilities for that? Why not use them?
As providers of a library we should not enforce how people use CMake, i.e. whether they use the automatic INSTALL_RPATH_USE_LINK_PATH or whether they want to decide manually. So the LIBRARY_DIR variable should be provided for that case. > Not using them is > rare enough that it would be ok to read the LOCATION property from the > imported target instead of setting the variable. Personally I can't judge whether setting the RPATH manually is used rarely or not. In KDE we do it automatically, but we are looking outside the KDE community now. Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
