Sudeep Mohanty
e364a60769
Add pytest test coverage for cmakev2 build system examples that had none. CMakeLists.txt fixes required to enable testing: conditional_component and plugins: added idf_build_generate_flasher_args() since these use the low-level build API (idf_build_executable / idf_flash_binary) which unlike idf_project_default() does not call it automatically. Without it, flasher_args.json was missing from the build output and pytest-embedded could not initialize the DUT. multi_binary: both app1 and app2 were registered in the global flash target via idf_flash_binary(...FLASH), creating a duplicate key at offset 0x10000 in the flasher_args.json generator expression and preventing the file from being generated. Fixed by removing FLASH from app2's call so only app1 is registered in the global flash target. idf_build_generate_flasher_args() now produces a valid flasher_args.json with app1 as the default app binary. The test patches the binary path to app2.bin when testing the second app.
| Supported Targets | ESP32 | ESP32-C2 | ESP32-C3 | ESP32-C5 | ESP32-C6 | ESP32-C61 | ESP32-H2 | ESP32-H21 | ESP32-H4 | ESP32-P4 | ESP32-S2 | ESP32-S3 | ESP32-S31 |
|---|
Conditional Component Inclusion Example
This example demonstrates how to conditionally include components at build time using Build System v2's pure CMake approach. Components are included or excluded based on Kconfig configuration options, and all components are written using standard CMake functions rather than IDF-specific abstractions.
Overview
In Build System v2, components can be written as plain CMake static libraries using add_library, target_link_libraries, and target_include_directories. A component is brought into the build on demand by calling idf_component_include(), which sets up the component's target name and invokes its CMakeLists.txt. Dependencies on other components are expressed using the idf::<name> alias targets.
This example uses that mechanism to conditionally pull in two utility components — logging_util and math_util — from within the main component, based on Kconfig options.
Project Structure
The project is initialized manually with idf_project_init() and idf_build_executable(), which gives precise control over which components are seeded into the build. The main component itself is a pure CMake static library. It conditionally includes logging_util and/or math_util at configure time by calling idf_component_include() inside if(CONFIG_...) guards and linking the resulting targets with target_link_libraries.
logging_util depends on IDF's log component for ESP_LOG* macros. It pulls log into the build with idf_component_include(log) and links it via the idf::log alias target. math_util has no IDF dependencies and is a self-contained static library.
Configuration Options
Two Kconfig options control which components are included:
CONFIG_EXAMPLE_ENABLE_LOGGING— includes and links thelogging_utilcomponent.CONFIG_EXAMPLE_ENABLE_MATH— includes and links themath_utilcomponent.
Both default to enabled. Toggle them via menuconfig under Conditional Component Example Configuration.
Building
cd examples/build_system/cmakev2/conditional_component
idf.py set-target <target>
idf.py build
To change which components are included, run idf.py menuconfig before rebuilding.
Output
With both components enabled the serial output shows info and warning log messages from logging_util and the results of add, subtract, and multiply operations from math_util. Disabling either option removes the corresponding section and replaces it with a "DISABLED" message.