Why make -j8 flash rebuilds the project?

[bonmotwang]

Is there a switch for just flash without rebuilding the whole project?
I am using Eclipse.
Thanks
Paul

[username]

yes, All the options are in the docs.

[ESP_Angus]

Hi Paul,

Similar to answer to your other question, make flash should only build any changed files and then flash the just-built app. If no source files have changed, it will just flash the app.

If you've changed menuconfig, the whole project is rebuilt with the new configuration.

If you only need to change the COM port for flashing, you can set the ESPPORT variable instead of editing menuconfig. ie run the command line "make -j4 flash ESPPORT=COM9". This will save an unnecessary rebuild just for the port change.

[chegewara]

Hi,
recently i found that changing Makefile also is causing full project rebuild.

[fly135]

Is there a switch for just flash without rebuilding the whole project?
I am using Eclipse.
Thanks
Paul

Here's an example using msys32 command line...

$IDF_PATH/components/esptool_py/esptool/esptool.py --chip esp32 --port "COM3" --baud 921600 --before "default_reset" --after "hard_reset" write_flash -z --flash_mode "dio" --flash_freq "40m" --flash_size detect 0x1000 ./build/bootloader/bootloader.bin 0x10000 ./build/<application name>.bin 0x8000 ./build/<partition file name>.bin

[ESP_Angus]

Hi,
recently i found that changing Makefile also is causing full project rebuild.

It has to do this because there's no way for Make to know what you changed. For example, if the change added a compiler flag to CFLAGS for every source file compilation then it needs to rebuild every source file to get the correct build output. The exact change can be subtle, so we rebuild the whole project if any top-level makefile changes.

[ESP_Angus]

Is there a switch for just flash without rebuilding the whole project?
I am using Eclipse.
Thanks
Paul

Here's an example using msys32 command line...

$IDF_PATH/components/esptool_py/esptool/esptool.py --chip esp32 --port "COM3" --baud 921600 --before "default_reset" --after "hard_reset" write_flash -z --flash_mode "dio" --flash_freq "40m" --flash_size detect 0x1000 ./build/bootloader/bootloader.bin 0x10000 ./build/<application name>.bin 0x8000 ./build/<partition file name>.bin

To expand on this answer, if you do a normal "make" build then the correct esptool.py flashing command is printed as the last output of the build. Running make and then running this command is the same as running "make flash".

[gunar.kroeger]

Hi,
recently i found that changing Makefile also is causing full project rebuild.

It has to do this because there's no way for Make to know what you changed. For example, if the change added a compiler flag to CFLAGS for every source file compilation then it needs to rebuild every source file to get the correct build output. The exact change can be subtle, so we rebuild the whole project if any top-level makefile changes.

Ok, but this behavior stopped me from being able to autoincrement the build version on each build. Is there a way of doing this without rebuilding everything?

[ESP_Angus]

Ok, but this behavior stopped me from being able to autoincrement the build version on each build. Is there a way of doing this without rebuilding everything?

Probably... put something like this in your Makefile

Code: Select all

ifndef MAKE_RESTARTS
_IGNORE := $(shell ./increment_build_number.sh)
endif

(Put it outside of any target)

Then, in your increment_build_number.sh script (can actually be a Python script or a PHP Script or a C program or whatever you like) it does the following steps:

• Open file main/build_number.h (or similar named file with build number)
• Parse the file to get the existing build number
• Add one to the build number
• Write the new file back with the new build number

This will update build_number.h each time "make" is run. The build system will rebuild only source files which include "build_number.h".

(Haven't tested this, 95% sure it will work though. Please open a new thread with your script if it's not working for you.)

EDIT PS: For what it's worth, I recommend not doing this and storing your project in git instead, with frequent commits. Knowing which git revision your project was built from (this is built-in functionality to ESP-IDF) is much more meaningful than knowing a build number.