Hierarchical Scopes in platformio

1

Hi

I have a project for esp8266 and esp32. For each cpu, I support various boards, sometimes different features are enabled for different builds.

Does platformio supports hierarchical scopes? Or is this feature planed?

It would be great, if the envoriment [env:esp8266:xyz] uses the config from [env:esp8266] and also from [env]

Example:

[env]
; Config for all Builds

[env:esp32]
; Config for esp32-Builds

[env:esp8266]
; Config for esp8266-Builds

[env:esp32:dev]
; Config for one esp32 Board

[env:esp8266:dev]
; Config for one esp8266 Board
1 Like
2

I LOVE this idea. This would definitely simplify my config files!

3

Have you seen this Redirecting...?

You can create custom scopes and use them later:


[env]
; global for all envs

[esp32]
build_flags =...
..

[env:esp32:dev]
build_flags = ${esp32.build_flags}
1 Like
4

Hi,

yes, I know. It helps to limit the amount of changes, if an options is changed, but I still have to add many, many lines to the platformio.ini.
I attached my platform.ini below. It already uses the new [env] feature in Version 4.

I still have to add the board_build and the platform options in every single esp8266 section. I can not add them to [env], because it isn’t needed for the esp32-sections.

With Version 4, the [env:*]-section are “inheriting” from the [env].

My proposal would be:
[env:esp8266:X] inherts from [env:esp8266] and [env:esp8266] from [env].
So [env:esp8266:X] has all the configs from [env:esp8266] and [env].

[env]
framework = arduino
lib_deps =
    Adafruit MCP23017 Arduino Library@1.0.3
    ArduinoJson@6.10.1
    LinkedList


upload_port = /dev/ttyUSB0
upload_speed = 921600
upload_protocol = esptool
upload_resetmethod = nodemcu

monitor_port = /dev/ttyUSB0
monitor_speed = 115200


[env:d1_mini]
; espressif8266@1.8.0  => 2.4.2
platform = espressif8266@1.8.0 
board = d1_mini
board_build.mcu = esp8266
board_build.f_cpu = 80000000L
board_build.flash_mode = dout

build_flags =
    -DARDUINO_ESP8266_WEMOS_D1MINI

[env:nodemcu]

platform = espressif8266@1.8.0
board = nodemcu
board_build.mcu = esp8266
board_build.f_cpu = 80000000L
board_build.flash_mode = dout

build_flags =
    -DARDUINO_ESP8266_NODEMCU

[env:nodemcuv2]

platform = espressif8266@1.8.0
board = nodemcuv2
board_build.mcu = esp8266
board_build.f_cpu = 80000000L
board_build.flash_mode = dout

build_flags =
    -DARDUINO_ESP8266_NODEMCU

[env:esp8285]

platform = espressif8266@1.8.0
board = esp8285
board_build.mcu = esp8266
board_build.f_cpu = 80000000L
board_build.flash_mode = dout


build_flags =
    -DARDUINO_ESP8266_ESP01


[env:esp32dev]

platform = espressif32
board = esp32dev

build_flags =
    -DESP32


[env:mhetesp32minikit]

platform = espressif32
board = mhetesp32minikit

build_flags =
    -DESP32



[env:esp32full]

platform = espressif32
board = mhetesp32minikit

build_flags =
    -DLY_FEATURE_AUDIO

lib_deps =
    ${env.lib_deps}
    earlephilhower/ESP8266Audio
    Gianbacchio/ESP8266_Spiram
6

Please re-test with the latest development version of PlatformIO Core 4.1:

pio upgrade --dev

http://docs.platformio.org/en/latest/projectconf/section_env_advanced.html#extends

I would be thankful for your feedback.

1 Like
7

Great … Thanks for implementing this feature

I tested it successfully.
I was able to shorten the platoformio.ini by 30%.

Great.

2 Likes
8

Perhaps I’m doing something wrong but is this applicable also on Windows? It appears that : is not allowed in filesystem names and so the following in builder/main.py throws:

if not isdir(env.subst("$BUILD_DIR")):
    makedirs(env.subst("$BUILD_DIR")) # NotADirectoryError: [WinError 267] The directory name is invalid: '...\esp32:dev':

@ivankravets

9

Did you call your environment [env:esp32:dev]? The name after env should not contain illegal characters in the context of the filesystem. Rename it to e.g. [env:esp32dev].

2 Likes
10

I see, I misunderstood the principle. Thank you. My concrete example had the following env names:

[platformio]
...

[env]
...

[app]
...

[env:app:penboard_stlink]
...

[env:app:penboard_dfu]
...

[env:boot]
...

I incorrectly presumed that the colons cause the intermediate scope to be inherited automatically.