Finding kf5 libs (Re: Move kde-config to kde4support.)

David Faure faure+bluesystems at kde.org
Fri Feb 22 21:39:14 UTC 2013


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, faure at kde.org, http://www.davidfaure.fr
Sponsored by BlueSystems and KDAB to work on KDE Frameworks



More information about the Kde-frameworks-devel mailing list