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). 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'. There's no precedent, reason or requirement to support imaginary use-cases. Let's start with minimal Config files. If we find later (during our experience of porting applications to use frameworks) that there's something that really really should be in all the Config files, let's add it then. Thanks, Steve. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
