| Summary: | eSDK: add a more practical means of adding components at build time | ||
|---|---|---|---|
| Product: | [Yocto Project Subprojects] eSDK | Reporter: | Paul Eggleton <bluelightning> |
| Component: | eSDK | Assignee: | Unassigned <unassigned> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | randy.macleod, ross.burton, wmills |
| Version: | unspecified | ||
| Target Milestone: | Future | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
|
Description
Paul Eggleton
2016-11-04 03:52:14 UTC
I should note that this is the eSDK equivalent of the standard SDK's TOOLCHAIN_HOST_TASK (and probably TOOLCHAIN_TARGET_TASK for that matter). I'm sure there's a good reason, but shouldn't it be possible to extend SDK and eSDK the same way? Potentially - the issue is that the namespace is entirely different. eSDK's host part is the native sysroot, whereas the standard SDK uses a nativesdk sysroot for the same thing, so TOOLCHAIN_HOST_TASK is expressed in terms of nativesdk packages. We could certainly translate all the items in TOOLCHAIN_HOST_TASK to native recipes, I just worry that there won't always be a 1-1 match. Still worth doing when we have the people available. -- YP bug review. Still worth doing when we have the people available. -- YP bug review. |