| Summary: | The layer priorities are not obeyed properly | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Toaster | Reporter: | Sujith H <sujith.h> |
| Component: | toaster | Assignee: | Toaster default assignee <toaster> |
| Status: | RESOLVED NOTABUG | QA Contact: | Mihail Stanciu <stanciux.mihail> |
| Severity: | normal | ||
| Priority: | Undecided | CC: | belen.barros.pena, bluelightning, jessica.zhang, stanciux.mihail |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | ppc | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Sujith H
2015-12-07 10:59:56 UTC
So there may well be a bug relating to layer priorities; but do note that when a bbclass is found in multiple layers, layer priority *does not* control which one is picked up - that's controlled solely through BBPATH. Since it's each layers' layer.conf that sets BBPATH, it can be influenced by the order in which the layer appears in bblayers.conf; additionally the layer.conf may choose to append or prepend to BBPATH which will also affect the overall order of paths in the final BBPATH value. Paul Eggleton, thanks a ton for pointing out about BBPATH. What I have observed is that command line builds are successfully creating images. I will update/share BBPATH values accordingly here ( once I reach office ) I have verified today by looking into the bblayers.conf file. So lets say if there are layers in the order ( after sourcing of meta-mentor/setup-environment script) a , b , c. The toasterconf.json file is having layer information in the reverse order: c, b , a. And as a result when toaster is executed from the terminal, the layer order remains as: c, b , a. And hence as Paul Eggleton suggested, the issue lies in the BBPATH. So I tried to rectify it in my custom script which creates toasterconf.json file. And which resolved the issue. Marking this issue as Resolved->Notabug. |