linux/poky.git/bitbake/lib/bb/tests/data.py, branch scarthgap-5.0.15

bitbake: bitbake: tests: Fix duplicate test_underscore_override test

2023-12-02T18:04:23+00:00

Found a duplicate test, added _2 suffix to one, 74 tests now pass up from 73. (Bitbake rev: ae2a19dadb4f3065b8731a61f45f29e6a70af402) Signed-off-by: Richard Haar Signed-off-by: Richard Purdie

bitbake: bb.tests.data: don't require the func flag for context functions

2023-08-04T10:37:56+00:00

Update test_python_snippet_function_reference to not require the 'func' flag, now that we know the real function will be returned for context functions without the flag. (Bitbake rev: 83f41281ec3d9b4327ffc8e2312e1fb8f53cbf02) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: tests.data: add test for builtin preferred over metadata value

2023-08-04T10:37:56+00:00

This test makes sure that '${@eval()}' calls the eval builtin, even if an 'eval' variable is defined in the metadata. (Bitbake rev: e9150447738a48f772240874b3512b08e982b19b) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: tests.data: add test for inline python calling a def'd function

2023-08-04T10:37:55+00:00

This is a test for an issue seen long ago, to avoid regressions, where a reference to a def'd function in the metadata would return the string value from the metadata rather than the function in inline python. (Bitbake rev: 9f7cb22febd557817c164e25a93f5660e9c06358) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie

bitbake: data_smart: allow python snippets to include a dictionary

2022-11-10T14:43:06+00:00

[YOCTO #14917] Attempting to use a dictionary in a python code snippet for variable assignment results in an error. For example attempting something such as IDX = "green" VAL = "${@{ 'green': 1, 'blue': 2 }[d.getVar('IDX')]}" produces the error expansion of VAL threw ExpansionError: Failure expanding variable VAL, expression was ${@{ 'green': 1, 'blue': 2 }[d.getVar('IDX')]} which triggered exception SyntaxError: '{' was never closed (Var , line 1) The existing __expand_python_regexp__, "\${@.+?}", will match the first close curly bracket encountered, resulting in incomplete and un-parsable code, and thus produce the error. We can correct this by allowing a single depth of nested curly brackets in __expand_python_regexp__ by using "\${@(?:{.*?}|.)+?}", which will match up to and including the matching close curly bracket to the open, '${@', curly bracket, even if there are one or more singly nested curly brackets present. This change allows the usecase described above to function. This change can't be made on its own though. The old regex would, in an obscure way, handle the case where a python snippet contained an unexpandable variable. Since the unexpandable variable is in curly brackets it would cause incomplete/un-parsable python code and thus remain unparsed. So something like VAL = "${@d.getVar('foo') + ${unsetvar}}" would remain unparsed as the close curly bracket in "${unsetvar}" would match and terminate the snippet prematurely. This quirk resulted in the proper handling of python snippets with unexpanded variables. With the change to __expand_python_regexp__ the full snippet will match and be parsed, but to match the old/correct behavior we would not want to parse it until ${unsetvar} can be expanded. To ensure the old/correct behavior for python snippets with unexpanded variables remains in place we add a check for unexpanded variables in the python snippets before running them. This handling of unparsed variables brings two benefits. The first we now have an explicit check visible to all for unexpanded variables instead of a somewhat hidden behavior. The second is that if there are multiple python snippets the old behavior would run the code for each but a single snippet with unexpanded variables would mean all snippets would remain unparsed, meaning more and repeated processing at a later time. For example: "${@2*2},${@d.getVar('foo') ${unsetvar}}" old behavior would give: "${@2*2},${@d.getVar('foo') ${unsetvar}}" new behavior will give: "4,${@d.getVar('foo') ${unsetvar}}" The old behavior would calculate '2*2' but toss the result when the second snippet would fail to parse resulting in future recalculations (or fetching from cache), while the new behavior avoids this. (Bitbake rev: 94e49b9b9e409c29eb04603b1305d96ebe661a4b) Signed-off-by: Mark Asselstine Signed-off-by: Richard Purdie

bitbake: data_smart: Fix inactive overide accidental variable value corruption

2021-08-04T09:38:43+00:00

Setting something like: BAR:append:unusedoverride should cause BAR to be None, not "" which was what the datastore was returning. This caused problems when mixing variables like: RDEPENDS:${PN}:inactiveoverride RDEPENDS:${BPN} since key expansion would report key overlap when there was none. This is a bug in the datastore. Fix it and add a test too. [YOCTO #14088] (Bitbake rev: 699e36c270d863258502d315ed00a1b940bfbf96) Signed-off-by: Richard Purdie

bitbake: doc/lib: Add fixes for issues missed by the automated conversion

2021-08-02T14:44:10+00:00

The examples and tests use non-standard override names, convert these to the new syntax by hand. (Bitbake rev: a6c40eca1146c0160da7e4e0bd7ac52fef2029e0) Signed-off-by: Richard Purdie

bitbake: doc/lib: Update to use new override syntax containing colons

2021-08-02T14:44:10+00:00

This runs the overrides conversion script in OE-Core over the bitbake code base including the docs. A handful of things were excluded in toaster and for the Changelog file. (Bitbake rev: 47f8d3b24fd52381bf3b41e2f55a53e57841344c) Signed-off-by: Richard Purdie

bitbake: lib: fix most undefined code picked up by pylint

2020-08-25T17:14:53+00:00

Correctly import, and inherit functions, and variables. Also fix some typos and remove some Python 2 code that isn't recognised. (Bitbake rev: b0c807be5c2170c9481c1a04d4c11972135d7dc5) Signed-off-by: Frazer Clews Signed-off-by: Richard Purdie

bitbake: data/siggen: Don't expand ignored variables

2020-04-06T15:45:34+00:00

If a variable is in the signature whitelist, we'd currently expand it, then later ignore the data. This is problemtic for code which has effects when expanded, recently source date epoch in OE-Core for example. We don't actually need to do this, if we pass the whitelist into the earlier function it can avoid the expansion. This also also give a small performance boost since we avoid running code in some cases. [YOCTO #13581] (Bitbake rev: f483ee4a869fb1dafbe4bdf2da228cdaa40b38bd) Signed-off-by: Richard Purdie