Implement "release" and "debug" folder per build environment

[Navis-Raven]

Please follow this steps:

1. you make a normal Build+Upload of a blinky code: The first time it takes time, and it's normal since it's the first time
2. you make a a little modification in the code, then build : This time since it's an incremental build, it doesn't take too much time.
3. start a debug sessions: it takes time, and it's normal.
4. Stop debug session
5. Now upload again your code (even without any modification) and here is the problem ! : it recompile the whole code and it take much time again !!!! And for ESP-IDF it tooks 250 second for my PC just to build a simple blinky code !

And I think it's the same for PIO unit testing.

Suggestion:
I suggest the solution that PIO treats Debug builds, Realase builds and Unit test builds as different buids in different directories, in order to not recompiling the whole code each time. See by yourself

[ivankravets]

Thanks for the issue! Please open PlatformIO IDE > Activity Bar (alien icon) > Updates > Upgrade PlatformIO Core.

See updated docs: https://docs.platformio.org/en/latest/projectconf/section_env_general.html#targets

Does it work now?

[Navis-Raven]

@ivankravets no, unfortunately it didn't work for me.

even if I add "targets = debug" in platform.ini, when I repeat the steps 1 to 5 I have always the same problem, it recompile !

platform.ini:

[env:esp wrover kit]
platform = espressif32
framework = arduino
board = esp-wrover-kit
monitor_speed = 115200
debug_tool = ftdi
targets = debug

However, I suggested that this feature to be implemented by default in the system as well as many other IDE like visual studio, eclipse etc... so that, the debug firmware is always separated from the run/release one. If this is implemented don't forget that clean project should clean all of debug and release binaries.

[ivankravets]

I've just added a separate page with detailed explanation http://docs.platformio.org/en/latest/projectconf/build_configurations.html

I checked it and it works for me. Be sure that you use PlatformIO Core 3.6.1a2

[Navis-Raven]

Ok I'll make some tests.
PIO version: PlatformIO, version 3.6.1a2

Test A:

ini file:

[env:esp_wrover_kit]
platform = espressif32
framework = espidf
board = esp-wrover-kit
monitor_speed = 115200
debug_tool = ftdi

[env:debug]
platform = espressif32
framework = espidf
board = esp-wrover-kit
monitor_speed = 115200
debug_tool = ftdi
targets = debug

Step 1: Build result: it compiles the two environnements at once !!

===================================================================================================== [SUMMARY] =====================================================================================================
Environment esp_wrover_kit      [SUCCESS]
Environment debug               [SUCCESS]
=========================================================================================== [SUCCESS] Took 448.93 seconds ===========================================================================================

Step 2: Debug session results he recompiled esp_wrover_kit environnement and skept debug environnement

===================================================================================================== [SUMMARY] =====================================================================================================
Environment esp_wrover_kit      [SUCCESS]
Environment debug               [SKIP]
=========================================================================================== [SUCCESS] Took 310.26 seconds ===========================================================================================

Step 3: Normal Uploading: It recompile and upload both

===================================================================================================== [SUMMARY] =====================================================================================================
Environment esp_wrover_kit      [SUCCESS]
Environment debug               [SUCCESS]
=========================================================================================== [SUCCESS] Took 419.57 seconds ===========================================================================================

going to Test B: (same steps)

[ivankravets]

See platformio/platformio-docs@5fde995

[Navis-Raven]

Test B: I did the same test just as the example in the documentationbut same results.

[env:release]
platform = espressif32
framework = espidf
board = esp-wrover-kit
monitor_speed = 115200
debug_tool = ftdi

[env:debug]
platform = espressif32
framework = espidf
board = esp-wrover-kit
monitor_speed = 115200
debug_tool = ftdi
targets = debug

now Test C : I'll see platformio/platformio-docs@5fde995and do this instead

[platformio]
env_default = esp wrover kit

[env:esp_wrover_kit]
platform = espressif32
framework = espidf
board = esp-wrover-kit
monitor_speed = 115200
debug_tool = ftdi

[env:debug]
platform = espressif32
framework = espidf
board = esp-wrover-kit
monitor_speed = 115200
debug_tool = ftdi
targets = debug

(test takes some time with ESP-IDF)

[Navis-Raven]

Test C:
Step1: Success

===================================================================================================== [SUMMARY] =====================================================================================================
Environment esp wrover kit      [SUCCESS]
Environment debug               [SKIP]
=========================================================================================== [SUCCESS] Took 226.52 seconds ===========================================================================================

Step 2: The test C fails here since it compile the release instead "esp wrover kit environnement of debug one

===================================================================================================== [SUMMARY] =====================================================================================================
Environment esp wrover kit      [SUCCESS]
Environment debug               [SKIP]
=========================================================================================== [SUCCESS] Took 317.90 seconds ===========================================================================================

Step 3: Fails also since it recompiles the default environnement

===================================================================================================== [SUMMARY] =====================================================================================================
Environment esp_wrover_kit      [SUCCESS]
Environment debug               [SKIP]
=========================================================================================== [SUCCESS] Took 239.59 seconds ===========================================================================================

[Navis-Raven]

@ivankravets I've just detected another issue while doing some tests with my STM32 board about incremental compilation.

Steps to reproduce:
Start debug session with a blinky
Stop debug session
Modify the code of blinky a little bit (change the blinks time lapse for example)
Start again the debug session:
The code doesn't recompile, ad go with the previous code ! And you can verify this by watching the led which did not change its blink frequency.

[env:disco_l475vg_iot01a]
platform = ststm32
board = disco_l475vg_iot01a
framework = stm32cube
debug_tool = stlink
test_transport = custom

[ivankravets]

Oh, you totally strayed me. It seems that I should revert all changes and back default debug configuration to "Debug with Pre-Debug Task". This task checks a project for changes.

Previous "Debug (Skip Pre-Debug)" means that "start debugging" without project building and checking. It is super fast but a developer is responsible to rebuild project and reflash board.

I'm not sure that it's good. Need to think on better solution.

[ivankravets]

http://docs.platformio.org/en/latest/projectconf/section_env_debug.html#debug-load-mode

It seems that we should CHECK project for changes for "always" and "modified" modes. The only in "manual" debug_load_mode we should not pre-process project.

What do you think? Is this "Pre-Debug" task useful? I mean, when we run it firstly in Terminal, then you need back manually to debug console.

[Navis-Raven]

Need to think on better solution.

This is what I suggested you from the beginning: to go for a simpler and better solution.
These configuration for a simple and popular feature was complicated for the "PlatformIO, PlatformIO " the easy to use platform with less configuration. Look at what I suggested you: it is to output debug and release firmwares version in two different directories: when you start a the debug session it will check from the previous debug firmware, and if you do a simple upload it will do the same for release, and no more complex configuration or complicated things. And it will be transparent for the user (useless to make configurable options for this, it's obvious that the debug firmware shouldn't mix with the release one). Just to avoid future bugs: If this is the solution implemented don't forget that clean project should clean all of debug and release binaries. And I suggest also to do also the same with "unit test" and make also the output in a unit_test dedicated diretory

It is super fast but a developer is responsible to rebuild project and reflash board.

Notice that the documentation does not mention this explanation sould be added.
http://docs.platformio.org/en/latest/ide/vscode.html#debugging

The documentation says, that the pre-debug add a task to prompt errors in the terminal, and not skipping pre-checking ("without project building and checking")

What do you think? Is this "Pre-Debug" task useful?

I didn't even have a clue until today of what is pre-debug and this is why i openned a documentation issue here: platformio/platformio-docs#36 (comment)
I think it can be useful if it is well explained in the documentation.

back default debug configuration to "Debug with Pre-Debug Task". This task checks a project for changes.

Yes this is what it should be, with Pre-Debug by default, because the Pre-Debug always check the code if it is modified.

Oh, you totally strayed me

LoL but you're developping too fast hahaha, this was an enhancement not a bug, I though that I would take you a little bit more time to think about it and to implement. I declared this issue just one day ago.

debug_load_mode we should not pre-process project

Personnaly, I don't use this "manual" option I find it too risky and not so useful, since the rechecking files does not take too much time for me, so I let default options. In the contrary "always" and "modified" can be usefu.l The manual option can be useful just for some very particular usage.

[ivankravets]

Thanks! I reverted back all changes and updated docs. Please run "Upgrade PlatformIO Core" again.

I reopened this issue and changed a title. These changes will affect existing projects/users who depend on the current structure of build artifacts. See related issue #1778

So, after these changes, the artifacts will be located in PROJECT DIR > BUILD_DIR > ENV_NAME > RELEASE | DEBUG > ...

Will that resolve this issue?

[Navis-Raven]

These changes will affect existing projects/users who depend on the current structure of build artifacts.

I don't know how platformIO is functionning, but my suggestion will affect only binary .a .o and output directories which will not be harmful for the majority of users. But it can affect for example those who use automation in code generation with platformIO cli. If you fear that it will affect these users you can reserve this enhancement for a future massive release (for example 4.x) in which you will indicate how to migrate from 3.x to 4.x as you've done with 2.x.

So, after these changes, the artifacts will be located in PROJECT DIR > BUILD_DIR > ENV_NAME > RELEASE | DEBUG > ...

And so that, the "clean" functionality will clean all files and directories under ENV_NAME

What about test ? Will it have its own directory also ? Like this
PROJECT DIR > BUILD_DIR > ENV_NAME > RELEASE | DEBUG | UNIT_TEST > ...

Will that resolve this issue?

I don't know how PlatformIO works, but I can guess that it will resolve it, and even if I will not resolve it, it will install the mechanisms to resolve it ! Because the only additionnal thing after that, is to ensure that checks for modifications are made separately and for each of debug, release and unit_test firmware.

[Navis-Raven]

@ivankravets
Can you take a look into this issue no one is assigned to it to this day, and it is an easy issues to correct: platformio/platform-espressif32#121

[ivankravets]

Duplicate of #2184

[Navis-Raven]

@ivankravets I didn't understand what happenned but the problem is still occuring in my ancient project.
If I build on release mode, then on debug mode, then on release again it recompile all things !

[env:disco_l475vg_iot01a]
platform = ststm32
board = disco_l475vg_iot01a
framework = mbed
debug_tool = stlink
build_flags = -D PIO_FRAMEWORK_MBED_RTOS_PRESENT

[ivankravets]

1. Please upgrade to PIO Core 4.0
2. Add build_type = debug to env:disco_l475vg_iot01a

[Navis-Raven]

I've already upgraded to 4.0

[Navis-Raven]

I ll do a test

[Navis-Raven]

@ivankravets So after adding build_type = debug it build always in debug mode whatever you click on build or pre-debug it does the same, and build the program in debug mode, isn't it ?

so how to switch easily from debug to release mode ?

[ivankravets]

There is good docs for this case http://docs.platformio.org/en/latest/projectconf/build_configurations.html

Please read.

[Navis-Raven]

@ivankravets

OK i did this, as on the documentation:

[env]
platform = ststm32
board = disco_l475vg_iot01a
framework = mbed
debug_tool = stlink
build_flags = -D PIO_FRAMEWORK_MBED_RTOS_PRESENT

[env:my__release]

[env:my__debug]
build_type = debug

but the result are not what I expected, the compilation take more times than before. If I click on build it will build both of my__release in release mode and my__debug in debug mode.

So for any change every time we will build it will build both of them.

However, if I click on pre-debug it only (incremental) builds the my__debug environnement, and ignores my__realease environnement. So what I understood is that when doing pre-debug mode, if it finds one or more "debug mode" environnement it ignores environnement in release mode isn't it ?

[ivankravets]

You need to build my__release in release mode, VScode Left Activity Bar > PlatformIO > Tasks or pio run -e my__release

As for the debugging, PlatformIO will automatically use my__debug for debug.

[Navis-Raven]

@ivankravets

Left Activity Bar > PlatformIO > Tasks > ....
what task to choose ?

[ivankravets]

Ahh, sorry, PlatformIO IDE for VSCode currently does not support templating for platformio.ini. We work on the new version.

A temporary solution is to do full old-style declaration:

[env:my__release]
platform = ststm32
board = disco_l475vg_iot01a
framework = mbed
debug_tool = stlink
build_flags = -D PIO_FRAMEWORK_MBED_RTOS_PRESENT

[env:my__debug]
build_type = debug
platform = ststm32
board = disco_l475vg_iot01a
framework = mbed
debug_tool = stlink
build_flags = -D PIO_FRAMEWORK_MBED_RTOS_PRESENT

[Navis-Raven]

OK I will retry the whole test now with this configuration.

[Navis-Raven]

@ivankravets

Look, if I click on build it still compile both of my_release and my_debug version

it is unfortunate that you've abandonned the initial solution of "Implement "release" and "debug" folder per build environment" that could be simpler.

[ivankravets]

You need to use env:my__release group... see below under Pre-Debug task

[Navis-Raven]

Ok I see