summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/command.py
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2023-05-09 13:55:01 +0100
committerRichard Purdie <richard.purdie@linuxfoundation.org>2023-05-25 13:16:24 +0100
commit695998f921b691f196825e9067b6db399d691e53 (patch)
tree29e013e9b3c5046d80974618a3c1e0d841fa1d27 /bitbake/lib/bb/command.py
parent3673a43c22f8adb98945501786077a77a798fb93 (diff)
downloadpoky-695998f921b691f196825e9067b6db399d691e53.tar.gz
bitbake: cooker: Add FILE_LAYERNAME variable containing the layername for a recipe
There are times when it would be useful for code to know which layer (or collection in old bitbake terms) it is contained within. Add support for FILE_LAYERNAME to be set by bitbake when parsing a recipe so that it is possible to determine this. To do it, we need to pass data from the cooker into the recipe endpoints, since only the top level cooker information knows about the layer structure which makes the patch a bit painful. The idea is that this would make layer overrides possible: OVERRIDES .= ":layer-${FILE_LAYERNAME}" which then opens possibilities like: WARN_QA:append:layer-core = " patch-fuzz" as an example where OE-Core could enable specific QA tests only for that specific layer. (Bitbake rev: 7090a14b0035842112d073acf7f2ed1a01fdeccf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'bitbake/lib/bb/command.py')
-rw-r--r--bitbake/lib/bb/command.py5
1 files changed, 3 insertions, 2 deletions
diff --git a/bitbake/lib/bb/command.py b/bitbake/lib/bb/command.py
index 9e2cdc5c75..a355f56c60 100644
--- a/bitbake/lib/bb/command.py
+++ b/bitbake/lib/bb/command.py
@@ -561,6 +561,7 @@ class CommandsSync:
561 appendfiles = command.cooker.collections[mc].get_file_appends(fn) 561 appendfiles = command.cooker.collections[mc].get_file_appends(fn)
562 else: 562 else:
563 appendfiles = [] 563 appendfiles = []
564 layername = command.cooker.collections[mc].calc_bbfile_priority(fn)[2]
564 # We are calling bb.cache locally here rather than on the server, 565 # We are calling bb.cache locally here rather than on the server,
565 # but that's OK because it doesn't actually need anything from 566 # but that's OK because it doesn't actually need anything from
566 # the server barring the global datastore (which we have a remote 567 # the server barring the global datastore (which we have a remote
@@ -568,10 +569,10 @@ class CommandsSync:
568 if config_data: 569 if config_data:
569 # We have to use a different function here if we're passing in a datastore 570 # We have to use a different function here if we're passing in a datastore
570 # NOTE: we took a copy above, so we don't do it here again 571 # NOTE: we took a copy above, so we don't do it here again
571 envdata = command.cooker.databuilder._parse_recipe(config_data, fn, appendfiles, mc)[''] 572 envdata = command.cooker.databuilder._parse_recipe(config_data, fn, appendfiles, mc, layername)['']
572 else: 573 else:
573 # Use the standard path 574 # Use the standard path
574 envdata = command.cooker.databuilder.parseRecipe(fn, appendfiles) 575 envdata = command.cooker.databuilder.parseRecipe(fn, appendfiles, layername)
575 idx = command.remotedatastores.store(envdata) 576 idx = command.remotedatastores.store(envdata)
576 return DataStoreConnectionHandle(idx) 577 return DataStoreConnectionHandle(idx)
577 parseRecipeFile.readonly = True 578 parseRecipeFile.readonly = True