| Summary: | rework oe-core's handling of python and sysroots | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Alexander Kanavin <alex.kanavin> |
| Component: | devtools / tool chain | Assignee: | Alexander Kanavin <alex.kanavin> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | meta.mr.watcher, meta.watcher, ross.burton |
| Version: | unspecified | ||
| Target Milestone: | 2.2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
|
Description
Alexander Kanavin
2016-03-04 10:44:19 UTC
I have fixed the HOST_SYS issue in 4977a0743ba439a46716c6ef10c5958d5a561115. After looking at this a bit closer (as a part of moving recipes to use python 3 where possible), I still don't have a clear idea how the redesign could look like. There is a million ways that software determines what the 'system' Python is, and there is no single way to take care of them all. Also, determining the system directories through patching distutils to use STAGING_INCDIR/STAGING_LIBDIR when building for target is not a bad approach, and I don't know how to replace it with something better. One incremental improvement is no longer force recipes to export these variables - the python(3)native class should take care of it. Patch that moves staging_inc/libdir to python(3)native.bbclass submitted. Patch merged. |