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

[Ben Cooksley]

On Sat, Feb 23, 2013 at 11:14 PM, Alexander Neundorf <neundorf at kde.org> wrote:
> On Friday 22 February 2013, Ben Cooksley wrote:
> ...
>> 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.
>
> I don't think the build bot should dictate how the buildsystem works.

This was just a warning that the proposed method would not work for
the CI system, to avoid work being wasted.

> Anyway, don't worry, we'll have a solution which works :-)
> After each installed "job" you extend CMAKE_PREFIX_PATH ?

The coordinator script sets up the environment before commencing a
build. It uses the information contained in the kde-build-metadata
repository to determine the dependencies of a given build, and sets
the appropriate environment variables up to make those dependencies
visible to the build.

CMAKE_PREFIX_PATH (among others) is included in the appropriate
environment variables.

Example: kde/kdelibs is marked as depending on: kdesupport/attica,
kdesupport/phonon/phonon, kdesupport/strigi/libstreams,
kdesupport/strigi/libstreamanalyzer, kdesupport/strigi/strigiclient,
kdesupport/polkit-qt-1, kdesupport/soprano.

Therefore, CMAKE_PREFIX_PATH will be setup containing the prefixes
where each one of those components is installed. (The above components
own dependencies are included as dependencies as well, along with qt
and automoc in this instance).

>
> Alex

Regards,
Ben