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

Burton, Ross ross.burton at intel.com
Wed Oct 10 14:15:54 UTC 2018


On Wed, 10 Oct 2018 at 15:12, Pascal Bach <pascal.bach at siemens.com> wrote:

> 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.


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.

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20181010/1070a12a/attachment-0002.html>


More information about the Openembedded-core mailing list