| Summary: | MACHINEOVERRIDES still inconsistent | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Jochen Trumpf <Jochen.Trumpf> |
| Component: | configuration | Assignee: | Richard Purdie <richard.purdie> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Undecided | ||
| Version: | 1.3 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
Patch out for review on OE-Core list. |
Following the recent commit 448efe65f51b996205dba009b0bdf25c19020d6f soc-family: fix SOC_FAMILY override order the contents of the variable MACHINEOVERRIDES are unfortunately still inconsistent (at least as far as I understand). It now lists SOC_FAMILY first, then MACHINE and then the active TUNE_FEATURES. Since the TUNE_FEATURES (armv7a in my case) are less specific than both SOC_FAMILY (omap3) and MACHINE (overo), they should come first, not last. This means, all the MACHINEOVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", [...] entries in meta/conf/machine/include/(ia32|arm)/*inc would need to be changed to '=.'. Additionally, this will only work if machine config files always read soc-family.inc first and then the tune files. The overo.conf file in meta-gumstix does it in the correct order, I have not checked any other machine configs. Not sure if there would be a better fix that does not depend on reading .inc files in a specific order. If not, this should be documented somewhere so people know to include soc-family.inc first. The easiest way to check your install for this is using bitbake -e | grep MACHINEOVERRIDES