Chapter 4. API Guides
– Consult the ExternalProject documentation for more details about externalproject_add()
• The second set of commands adds a library target, which points to the “imported”library file built by the
external system. Some properties need to be set in order to add include directories and tell CMake where this
file is.
• Finally, the generated library is added to ADDITIONAL_MAKE_CLEAN_FILES. This means make
clean will delete this library. (Note that the other object files from the build won’t be deleted.)
ExternalProject dependencies, clean builds CMake has some unusual behaviour around external project builds:
• ADDITIONAL_MAKE_CLEAN_FILES only works when “make”is used as the build system. If Ninja or
an IDE build system is used, it won’t delete these files when cleaning.
• However, the ExternalProject configure & build commands will always be re-run after a clean is run.
• Therefore, there are two alternative recommended ways to configure the external build command:
1. Have the external BUILD_COMMAND run a full clean compile of all sources. The build command will
be run if any of the dependencies passed to externalproject_add with DEPENDS have changed,
or if this is a clean build (ie any of idf.py clean, ninja clean, or make clean was run.)
2. Have the external BUILD_COMMAND be an incremental build command. Pass the parameter
BUILD_ALWAYS 1 to externalproject_add. This means the external project will be built
each time a build is run, regardless of dependencies. This is only recommended if the external project
has correct incremental build behaviour, and doesn’t take too long to run.
The best of these approaches for building an external project will depend on the project itself, its build system, and
whether you anticipate needing to frequently recompile the project.
4.4.13 Custom sdkconfig defaults
For example projects or other projects where you don’t want to specify a full sdkconfig configuration, but you do
want to override some key values from the ESP-IDF defaults, it is possible to create a file sdkconfig.defaults
in the project directory. This file will be used when creating a new config from scratch, or when any new config value
hasn’t yet been set in the sdkconfig file.
To override the name of this file or to specify multiple files, set the SDKCONFIG_DEFAULTS environment variable
or set SDKCONFIG_DEFAULTS in top-level CMakeLists.txt. If specifying multiple files, use semicolon as the list
separator. File names not specified as full paths are resolved relative to current project.
Some of the IDF examples include a sdkconfig.ci file. This is part of the continuous integration (CI) test
framework and is ignored by the normal build process.
Target-dependent sdkconfig defaults
In addition to sdkconfig.defaults file, build system will also load defaults from sdkconfig.defaults.
TARGET_NAME file, where TARGET_NAME is the value of IDF_TARGET. For example, for esp32 target, default
settings will be taken from sdkconfig.defaults first, and then from sdkconfig.defaults.esp32.
If SDKCONFIG_DEFAULTS is used to override the name of defaults file/files, the name of target-specific defaults
file will be derived from SDKCONFIG_DEFAULTS value/values using the rule above.
4.4.14 Flash arguments
There are some scenarios that we want to flash the target board without IDF. For this case we want to save the built
binaries, esptool.py and esptool write_flash arguments. It’s simple to write a script to save binaries and esptool.py.
After running a project build, the build directory contains binary output files (.bin files) for the project and also the
following flashing data files:
• flash_project_args contains arguments to flash the entire project (app, bootloader, partition table,
PHY data if this is configured).
• flash_app_args contains arguments to flash only the app.
Espressif Systems 1287
Submit Document Feedback
Release v4.4
To Next Page
Loading...
Need help?
General