Very helpful twitter convo with @esp_igrr helped me sort this out. TL:DR -- "not really, but also yes, sort of."
1: There are lots of things that simply can't be removed from the build. See the API Reference on "Build System" for the list of mandatorily-built components.
These components, and any dependencies they have, can't not be built.
https://docs.espressif.com/projects/esp ... quirements
2: There are some counter-intuitive components included in the minimum build. Here's @esp_igrr:
"In the past esp_wifi.h header file used to live in one of the "common" components, "esp32". To avoid regressions, when it was moved to esp_wifi component, esp_wifi was added as a dependency of "esp32". "
Since esp32 is always required, that means esp_wifi will always get built. There are a few other non-intuitive things in my build list (nsv_flash, tcpip_adapter). I assume they're stuck in there for similar reasons.
3. This affects the build time, but I don't think it affects the binary size. For me, unused code gets eliminated at link time. @esp_igrr mentioned enabling CCache; it think it's turned on by default in my VSCode plugin installation, so I haven't tested this.
4. To reduce the build time: include this line, in the *project* folder's CMakeLists.txt (NOT the main folder, but the project top-level folder):
NOTE: this doesn't preclude you from building/linking in other components. You're going to include those by listing them in the *component* folder CMakeLists.txt, and their dependencies will get included too.
Be careful about renaming your main folder! A folder named "main", containing a file named main.c, gets treated differently by CMake/ESP-IDF than other components. (See the link to the Build System API reference, linked above, for details).
All this line does is force CMake to trim components that aren't referenced by your code in any way. For reference, my top-level (project folder) CMakeLists.txt looks like this:
Code: Select all
cmake_minimum_required(VERSION 3.5)
set(COMPONENTS esptool_py main)
include($ENV{IDF_PATH}/tools/cmake/project.cmake)
project(main)
5. Wondering why ESP-IDF doesn't just assume this behaviour as default? Here's @esp_igrr:
There are a few reasons why even a simple ESP-IDF project builds a lot of files. IDF was developed mainly for IoT related products, and while we did make it extensible, not much effort was put into making it to scale down to simple applications.
Most real applications built for ESP chips will require these components anyway, so there is not much to gain, aside from build time, by leaving them out. We do see that trimming the build is needed sometimes, for example to be able to build many different test apps quickly.
Build time, code size, performance can all be improved once they get to a working application or demo; rather than having them figure out why the can't use some function or can't include some header file from the very start.
I was glad to learn this. It helps me understand, when something seems to work inconsistently, that I should consider if it makes the life of a new dev easier. If it does, it's likely not a bug. I was starting to doubt whether I had even understood CMake at all, until I understood this.
OVERALL
Adding the set(COMPONENTS...) line to my project-level CMakeLists.txt reduced built components from 966 to 613, and brought the build time down under 1 min. Not ideal, but understandable, and an acceptable compromise for the greater ease that will result once my projects are out of the "trivial driver" stage.