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

[Ben Cooksley]

On Sat, Feb 23, 2013 at 10:39 AM, David Faure <faure+bluesystems at 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, faure at kde.org, http://www.davidfaure.fr
> Sponsored by BlueSystems and KDAB to work on KDE Frameworks
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel