[OE-core] [PATCHv3 1/4] cmake.bbclass: use CMAKE_SYSTEM_LIBRARY_PATH instead of CMAKE_LIBRARY_PATH

[Pascal Bach]

On 10.10.2018 14:36, Richard Purdie wrote:
> On Wed, 2018-10-10 at 10:10 +0200, Pascal Bach wrote:
>> CMAKE_LIBRARY_PATH is intended to be set by projects.
>> CMAKE_SYSTEM_LIBRARY_PATH is better suited to be used in a toolchain
>> file.
>>
>> Signed-off-by: Pascal Bach <pascal.bach at siemens.com>
>> ---
>>  meta/classes/cmake.bbclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> I have a feeling something in this series may have caused:
>
> https://autobuilder.yoctoproject.org/typhoon/api/v2/logs/42753/raw
>
> but haven't bisected to confirm it is the cmake changes yet (it is from
> something in master-next).
>
The problem is "cmake.bbclass: allow cmake to find hosttools" it has the side effect of making all hosttools available to all recipes.
In the case of libproxy this leads to it finding python, which is included in hosttools, and thus building it's bindings.

This kind of defeats the purpose of having recipe specific sysroots.
Is there a way to make only selected hosttools available to a recipe. Like for example git? Maybe use git-native?

I think the patch "cmake.bbclass: allow cmake to find hosttools" in this form does more harm then good. The rest of the series should be fine.
Should I resubmit the series without this specific patch?

One more thing for libproxy. It currently disables python explicitly via `-WITH_PYTHON=no`. But this option doesn't exist anymore as it got replaces
by `-WITH_PYTHON2=no` `-WITH_PYTHON3=no`. This is why the auto detection kicks in. I will submit a patch to clean this recipe up too.

Pascal