On Sat, Feb 23, 2013 at 10:39 AM, David Faure <faure+bluesyst...@kde.org> wrote: > 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...
Just adding in here that if we split frameworks into multiple repositories, it is a absolute, unalterable requirement that frameworks CMake logic look into all prefixes in CMAKE_PREFIX_PATH for the various frameworks components. Otherwise, it will be absolutely impossible for build.kde.org to operate on the repositories. Each job (repository + branch) is installed into a different prefix, and this method of operation is crucial to how build.kde.org operates. Requiring that all frameworks libraries be installed in a single prefix will not work. Regards, Ben > > -- > 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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel