On Tuesday, September 13, 2011 08:27:27 PM Stephen Kelly wrote: > Hi, > > FindKDE4Internal has a macro _set_fancy which does some messing about with > the cmake cache and variables one might set (particularly paths). > > * Where does this feature belong?
It is very special. For some of the install destinations, it shouldn't be necessary at all. E.g. for the LIB_INSTALL_DIR and for INCLUDE_INSTALL_DIR, these two don't even have to be in the cache, so a simple set should do for them (as discussed in Randa). This has the positive effect that it is much easier to find the include and lib directory from a Config.cmake file. For some, it needs to be in the cache, e.g. the /etc-dir, SYSCONFIG I think. Additionally, it has the additional logic, that if kdelibs has already been installed to the current CMAKE_INSTALL_PREFIX, then it reuses all the install dirs from that kdelibs installation. This was a special request from some of our developers. Also, we always use full paths for install locations, which is not a good thing, since it creates problems on Windows. So this should be changed for kf5. > * Is it working around a cmake deficiency? Not really. > * Does cmake need to be fixed? Since 2.8.4 or 2.8.5 cmake comes with a GNUInstallDirs.cmake, which defines a set of install locations as cache variables. Maybe we should use that instead ? It puts all the install locations in the cache (including e.g. the one for headers, which IMO should not be modifiable). This also allows to use absolute paths in the install locations, which, for most locations, we shouldn't do. And of course, it doesn't and can't have the special logic for reusing the install locations if a kdelibs has been found in the same location. So, I'm not sure what to do. IMO, this is something KDE-specific, so it should/could be in some KDE- specific component, and if some software uses this component, it becomes a KDE software. Then we could just keep it as it is, including the set of install dirs which are defined in FindKDE4Internal.cmake. (similar to how we decide which compiler flags to use etc.) Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
