| Summary: |
Data.getVar doesn't support the expansion of nested variables |
| Product: |
[Build System, Metadata & Runtime] BitBake
|
Reporter: |
Igor Stoppa <igor.stoppa> |
| Component: |
bitbake | Assignee: |
Richard Purdie <richard.purdie> |
| Status: |
RESOLVED
WORKSFORME
|
QA Contact: |
|
| Severity: |
normal
|
|
|
| Priority: |
Undecided
|
CC: |
poky.bs.watcher, poky.watcher
|
| Version: |
unspecified | |
|
| Target Milestone: |
--- | |
|
| Hardware: |
x86 | |
|
| OS: |
Multiple | |
|
| Whiteboard: |
|
|
OS type for building Yocto:
|
---
|
Type of Regression:
|
---
|
|---|
|
Verified:
|
|
Documentation change:
|
Yes (doc changes required)
|
|---|
In a recipe, it is common to have a variable defined in terms of another, with various levels of nesting. Simple Ex: Precondition: ------------- VAR1 ?= "a" VAR2 ?= "${VAR1}b" Triggering Action: ------------------ running Data.getVar over VAR2 in a python script, within a recipe ex: print d.getVar("VAR2") Expected Outcome: ----------------- one would expect that it will yield "ab", just like it would happen if the expansion was performed within a shell script Actual Outcome: --------------- It will instead yield "${VAR1}b", which is somewhat less intuitive and definitely less usable, in typical scenario where one wants to have the final evaluation of the expression. Additional remarks: ------------------- One might argue that this is a feature request, rather than a bug, but I see the current implementation as a deviation from the behaviour of the existing variable expansion performed in shell context. I think it's fair to expect getVar to be the python counterpart of variable retrieval that in a shell is done with "{VAR2}" and therefore I think it should be expected that it behaves in a compatible way.