kolban wrote:
entry to explicitly name the the components I wish to include (the default would otherwise be all that could be found). However when I try this (for example setting COMPONENTS=nvs_flash), I find that the compilation of my app template now fails:
This is possible, but it's a bit sub-optimal right now. The core list of COMPONENTS for a minimal build is quite large, and the failures can be counter-intuitive (to say the least). This Makefile works with the idf-template repository:
Code: Select all
PROJECT_NAME := app-template
COMPONENTS=freertos esp32 newlib esptool_py nvs_flash spi_flash log tcpip_adapter lwip main xtensa-debug-module driver bt
include $(IDF_PATH)/make/project.mk
If you get strange compile errors when changing the list of components, you may also need to do a 'make clean'.
(It's worth noting that the resulting binary is the exact same size whether the list of components is trimmed or not, the only difference at the moment is the number of files compiled and then never linked.)
When we get time, we plan to make this process easier and more configurable (and the minimal subset of components a lot smaller!).
hydrabus wrote:Yes such feature will be great to speed up build time.
At the moment the best things you can do to speed up builds is to enable ccache (either via symlink, or by setting the compiler prefix to "ccache xtensa-esp32-elf-gcc") and to use parallel builds (ie make -jN).
However I agree that in the future being able to not compile certain components will help a lot.
hydrabus wrote:
I have tested -flto option on latest trunk esp/esp-idf/examples/02_blink (from today)
Adjusting the LDFLAGs is a bit tricky, that initial COMPONENT_LDFLAGS declaration is a false start unfortunately. You can do it like this:
Code: Select all
diff --git a/make/project.mk b/make/project.mk
index 67e2e92..60161e6 100644
--- a/make/project.mk
+++ b/make/project.mk
@@ -137,7 +137,7 @@ export PROJECT_PATH
# Set default LDFLAGS
-LDFLAGS ?= -nostdlib \
+LDFLAGS ?= -nostdlib -flto \
-L$(IDF_PATH)/lib \
-L$(IDF_PATH)/ld \
$(addprefix -L$(BUILD_DIR_BASE)/,$(COMPONENTS) $(SRCDIRS)) \
@@ -185,7 +185,7 @@ OPTIMIZATION_FLAGS = -Og
endif
# Enable generation of debugging symbols
-OPTIMIZATION_FLAGS += -ggdb
+OPTIMIZATION_FLAGS += -flto -ggdb
# List of flags to pass to C compiler
# If any flags are defined in application Makefile, add them at the end.
... however the binary will fail to link because of "call target out of range" errors.
As far as I know, this is a limitation of gcc xtensa support that will need to be fixed in the toolchain.
. LTO does work on very simple binaries with xtensa, for example I use it when building the stub flasher program for esptool.py (and it shaves off a substantial amount of the binary size as well.) It'd be great to be able to use it with esp-idf.
