<div dir="ltr">On Wed, 10 Oct 2018 at 15:12, Pascal Bach <<a href="mailto:pascal.bach@siemens.com">pascal.bach@siemens.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The problem is "cmake.bbclass: allow cmake to find hosttools" it has the side effect of making all hosttools available to all recipes.<br>
In the case of libproxy this leads to it finding python, which is included in hosttools, and thus building it's bindings.<br>
<br>
This kind of defeats the purpose of having recipe specific sysroots.<br>
Is there a way to make only selected hosttools available to a recipe. Like for example git? Maybe use git-native?<br>
<br>
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.<br>
Should I resubmit the series without this specific patch?<br>
<br>
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<br>
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.</blockquote><div><br></div><div>Per-recipe hosttools is an interesting idea but I'd say it's quite likely too invasive. This change has actually fixed cmake, and exposed the problem that the recipe is broken and should be using WITH_PYTHON2/WITH_PYTHON3: fixing that is the correct fix.</div><div><br></div><div>Ross </div></div></div>