Not sure if I’m doing something wrong here, but when build_flags
are inherited, they seem to not be able to resolve paramters. Example:
[env]
framework = arduino
lib_deps =
stm32duino/STM32duino ST25DV@^2.1.2
build_flags =
'-D APP_VERSION="0.0.0-${this.board}"'
[env:esp32-s3-devkitc-1]
platform = espressif32
board = esp32-s3-devkitc-1
build_flags =
${env.build_flags}
-D ESP32_S3
When building APP_VERSION
resolves to 0.0.0-dev+None
. If I re-declare the value in env:esp32-s3-devkitc-1.build_flags
it seems to work: v0.0.0-dev+esp32-s3-devkitc-1
.
Am I missing something or is this a bug?
Technically this is in accordance to the documentation that says
${this.}
Embed value from the current section without declaring a section name
${this.board} refers to the “board” value of the current section
And the current section is [env]
.
Now I’m really confused
, as if I don’t supply any build_flags
, it works. e.g.:
[env]
framework = arduino
build_flags =
'-D APP_VERSION="0.0.0-dev+${this.board}"'
[env:board1] ; <-- This correctly creates v0.0.0-dev+foo1
platform = espressif32
board = foo1
[env:board2] ; <-- This wrongly creates v0.0.0-dev+None
platform = espressif32
board = foo2
build_flags =
${env.build_flags}
-D ACME
Therefore, the [env]
argument doesn’t fit as for [env:board1]
it would suggest that should resolve to None
too, but it doesn’t.
Very interesting. Maybe @ivankravets knows more.
1 Like
The Python’s ConfigParser (INI) parses the contents line-by-line. AS result, there is no context at that stage 