summaryrefslogtreecommitdiffstats
path: root/meta/recipes-connectivity
diff options
context:
space:
mode:
authorDamien Riegel <damien.riegel@savoirfairelinux.com>2018-06-15 20:18:38 -0400
committerRichard Purdie <richard.purdie@linuxfoundation.org>2018-06-18 11:07:57 +0100
commit7d3ad1405ca3f891db82091f31783a650a6bc681 (patch)
tree5f6a0a8a40cd9c41289ff978a2af1226378ef695 /meta/recipes-connectivity
parent1ecb384c110706f210f9b3bc66772a2f5d89e904 (diff)
downloadpoky-7d3ad1405ca3f891db82091f31783a650a6bc681.tar.gz
populate_sdk_ext.bbclass: fix corebase identification
When generating the extended SDK, there is a copy step where this class goes through the layers and other stuff that have been copied to generate the SDK. The corebase; ie. the folder that contains the core layer 'meta' is treated in a special way. Unfortunately in our tree, we have: sources/meta/meta | `- core layer `------- corebase In populate_sdk_ext's copy_buildsystem, the heuristic to determine which element of the list returned by copy_bitbake_and_layers is corebase is fooled by such layout. In copy_bitbake_and_layers, corebase is already handled specifically and reliably, so we should let that function tell us which folder is corebase instead of trying to determine it. To do so, change the return type of copy_bitbake_and_layers to a tuple that contains (corebase, copied_layers). It also simplifies the code on the caller side. (From OE-Core rev: 5368bc5d0d3606198b93e877bcafcd77bb5f4fd1) Signed-off-by: Damien Riegel <damien.riegel@savoirfairelinux.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-connectivity')
0 files changed, 0 insertions, 0 deletions