On Friday 22 February 2013 18:54:45 Alexander Neundorf wrote: > On Friday 22 February 2013, David Faure wrote: > > [This is no longer about kde*-config, retitling] > > > > On Friday 22 February 2013 18:38:39 Alexander Neundorf wrote: > > > If you do > > > find_package(KF5 COMPONENTS kidletime kauth kconfig) > > > it will search the kidletime library, and once it has found it, it will > > > search kauth and kconfig only in the same prefix. > > > > Surely if it can find kidletime "anywhere" (I assume that's more precisely > > "in CMAKE_PREFIX_PATH"), it can find the others using the same algorithm? > > > > > If KDEDIRS is set, it searches afterwards also in those. > > > > Please get rid of KDEDIRS. Surely setting CMAKE_PREFIX_PATH can do this > > job just the same? > > No, it can't. > If you set it to /opt/mykf5/, cmake will search stuff there, and afterwards > in the standard locations, so you may get a mixture of libs.
But not if you have the necessary libs in /opt/mykf5, right? I'm confused. If kidletime, kauth all available in /opt/mykf5 they will be all selected. If kconfig is also searched and is only available in /usr, then it will be selected. If it's recent enough, isn't that better than "sorry, I only looked in one place and didn't find it?". If it's too old, then it should be rejected indeed. Maybe this means something like find_package(KF5 VERSION 5.1 COMPONENTS kidletime kauth kconfig) or whateever the right syntax is. > Making it easy to separate different installations of kf5 on the same system > from each other helps with this. Sure, and CMAKE_PREFIX_PATH makes this easy - you can make /opt/mykf5.1 completely invisible if you set it to contain only /opt/mykf5.2... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by BlueSystems and KDAB to work on KDE Frameworks _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
