PlatformIO Community

Dynamic execution of python script in platformio.ini not working, win10+vscode+platformio

I have recently installed vscode and platformio on win10.

If I have:-

    build_flags = -std=c++17 -std=gnu++17

Then with “pio run --target envdump” from PlatformIO CLI within vscode I see:-
‘BUILD_FLAGS’: [’-std=c++17 -std=gnu++17’]

But if I try this:-

    build_flags = !

All I get is:-

‘BUILD_FLAGS’: [’!’]

So clearly the python is not being executed.
The is in the same folder as platformio.ini.
Using the full path for doesn’t work either.
I have ‘PYTHONEXE’: ‘C:\Users\my_user\.platformio\penv\Scripts\python.exe’.
When I compile the project, build_flags is clearly not set with the expected cpp flags.

I see from another post that someone else has win10+vscode+platformio working for executing python scripts within the platformio.ini, so wondering what could be wrong with my setup?

Docs say that you should write !python <yourscript>, so does

build_flags = !python

do anything?

1 Like

Thanks for quick reply.
This gives
‘BUILD_FLAGS’: [’! python’]

While this may be true, the flag still ends up in CPPDEFINES for me. I just tested this:

platform = atmelavr
board = uno
framework = arduino
build_flags = !python



and pio run -t envdump shows

  'BUILD_FLAGS': ['!python'],
  'CPPDEFINES': [ ('PLATFORMIO', 60002),
                  ('MY_FLAG', 123),
                  ('F_CPU', '$BOARD_F_CPU'),
                  ('ARDUINO', 10808)],

So that’s actually working. The flag also shows up in the verbose build.

avr-g++ -o .pio\build\uno\src\main.cpp.o -c -fno-exceptions -fno-threadsafe-statics -fpermissive -std=gnu++11 -Os -Wall -ffunction-sections -fdata-sections -flto -mmcu=atmega328p -DPLATFORMIO=60002 -DARDUINO_AVR_UNO -DMY_FLAG=123 -DF_CPU=16000000L -DARDUINO_ARCH_AVR -DARDUINO=10808 -Iinclude -Isrc “-IC:\Users\Max Gerhardt.platformio\packages\framework-arduino-avr\cores\arduino” “-IC:\Users\Max Gerhardt.platformio\packages\framework-arduino-avr\variants\standard” src\main.cpp

1 Like

Many thanks, it turns out that “!python” is substituted later and it compiles correctly now.