On Tuesday 18 December 2012, Stephen Kelly wrote: > Alexander Neundorf wrote: > > 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. > > We can > > * make the common things easy (we don't need to do anything and people can > use INSTALL_RPATH_USE_LINK_PATH) > * make the less common things possible (We don't need to do anything and > don't prevent anyone from reading the LOCATION property and using > get_filename_component() as you did) > * Minimise the amount of things we put into the Config files (for > maintenance, so people don't bother adding 'missing' variables which are > not useful to the 20+ config files we'll maintain by hand) > * Encourage people to use idiomatic, modern cmake (so we don't have to > support imaginary use-cases).
This is IMO not imaginary (as far as any use cases of tier1 libraries actually can be non-imaginary right now ;-) ). At work, we set the RPATH manually. We know the limited number of libraries we link against, we want to have full control over the RPATH. I would be surprised if we would be the only ones. I wouldn't even say using INSTALL_RPATH_USE_LINK_PATH is better or more modern, it's IMO just more convenient for a big project as KDE is. > The choice not to pre-caclulate and maintain unused variables in Config > files is not a choice that enforces how anyone else uses CMake. > > > 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. > > Still though, we need to optimize for KDE-projects, and those are going to > use the 'KDE cmake settings'. > > That's something we've always done. kde4_add_executable and > kde4_add_library are already making choices about how the user can use > cmake with 'KDE stuff'. Now that the tier1 libraries are in somewhat good shape, I get a better feel for them. (their Config.cmake files are actually still not complete, they still lack the find_package() for the required Qt libraries) Having said that, I now consider them simple libraries, like qwt or qxt, which, if LGPL would not be a problem for us at work, we could simply use like any other library. I would be happy then if the library would provide me a karchive_LIBRARY_DIR variable, which I can use for the RPATH or not. ... ok, actually, we set the RPATH fix to a location inside our install hierarchy, ignoring any other directories. Another option would be to have get_target_property(_tmpSolidLocation KF5::solid LOCATION) get_filename_component(solid_LIB_DIR ${_tmpSolidLocation} PATH) in solidConfig.cmake. This way it wouldn't look like pre-calculated variables. But, actually if you look into the Targets-<buildtype>.cmake file, _IMPORT_PREFIX is also precalculated based on information from cmake time. So practically, it wouldn't change much. I mean, why should we not provide it ? We depend on that the information we have in the Config.cmake file is correct. If we are afraid that our calculated solid_LIB_DIR is wrong, then we have a bigger problem. Alex _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel