| Summary: |
Suggested additions to the MLPREFIX glossary entry |
| Product: |
[Documentation] Reference
|
Reporter: |
ulfalizer |
| Component: |
handbook | Assignee: |
Scott Rifenbark <srifenbark> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
|
| Severity: |
normal
|
|
|
| Priority: |
Medium
|
CC: |
bluelightning, poky.doc.watcher, poky.watcher, srifenbark
|
| Version: |
2.2 | |
|
| Target Milestone: |
2.2 M4 | |
|
| Hardware: |
x86 | |
|
| OS: |
Multiple | |
|
| Whiteboard: |
01 Sept 2016: RESOLVED |
|
OS type for building Yocto:
|
---
|
Type of Regression:
|
---
|
|---|
|
Verified:
|
|
Documentation change:
|
Done (doc changes complete)
|
|---|
Hello, I think adding the following to the end of the MLPREFIX glossary entry would demystify it a lot: Note { The "ML" in MLPREFIX stands for "MultiLib". This is historical and comes from a time when 'nativesdk' was a suffix rather than a prefix on the recipe name. When 'nativesdk' was turned into a prefix, it made sense to set MLPREFIX for it as well. } An example situation where MLPREFIX might be needed is when using [BBCLASSEXTEND] to provide a nativesdk version of a recipe in addition to the target version. If that recipe declares build-time dependencies on tasks in other recipes by using [DEPENDS], then a dependency on "foo" will automatically get rewritten to a dependency on "nativesdk-foo". However, dependencies like the following will not get rewritten automatically: do_foo[depends] += "some-recipe:do_foo" If you want such a dependency to also get transformed, you can do the following: do_foo[depends] += "${MLPREFIX}some-recipe:do_foo" Cheers, Ulf