In cmakev1, the executable target is named "${project}.elf". In cmakev2,
the executable is named "${project}" with .elf as the output suffix.
Strip the .elf suffix and look up the bare target name when the original
name doesn't exist.
Two compatibility fixes:
- idf_component_register: apply separate_arguments to REQUIRES and
PRIV_REQUIRES after cmake_parse_arguments. Some managed components
publish CMakeLists.txt with PRIV_REQUIRES "log esp_eth" as a single
quoted string (e.g. espressif__rtl8201).
- Add register_component() macro and idf_component_add_link_dependency()
shims for legacy ESP-IDF examples (ULP apps, BLE mesh) and managed
components (esp_flash_nor).
kconfgen runs while the component manager iterates to convergence.
Those passes operate on partial component sets and emit "unknown
kconfig symbol" warnings for symbols defined in not-yet-downloaded
components — idf-build-apps treats those as build failures.
Suppress kconfgen output on the intermediate passes; only the final
pass against the converged set emits warnings.
The cmakev2 compat layer's idf_component_register() was passing
${sources} quoted to add_library(), collapsing the semicolon-delimited
list into a single argument. Drop the quotes so each source becomes a
separate argument, matching cmakev1's idf_component_register().
The CMakeLists injects CONFIG_ESP_REV_MIN_FULL and CONFIG_XTAL_FREQ on
the command line because those symbols live in esp_common's Kconfig,
which is outside the G0 closure and is not loaded during a restricted
COMPONENTS build. When every discovered component's Kconfig is processed
(IDF_BUILD_V2) the symbols are already defined via their Kconfig
defaults, and the additional -D would conflict with the existing
definition.
Gate the injection so it only runs when the Kconfig is not processed.
g1_components forces VFS_SUPPORT_IO=n in sdkconfig.defaults to keep
vfs and its transitive deps out of the closure. When the restricted
COMPONENTS list does not load components/vfs/Kconfig, the symbol is
unknown at config time and kconfgen emits an "unknown kconfig symbol"
warning that idf-build-apps treats as a build failure.
Add an ignore pattern so the warning does not gate the build.
g1_components builds a minimal COMPONENTS list. When every component's
Kconfig is processed, components/vfs/Kconfig sets VFS_SUPPORT_IO=y by
default, and the conditional requires in esp_stdio and esp_libc pull
vfs, esp_driver_uart, and their transitive deps into the closure.
Add an sdkconfig.defaults that forces the symbol off so the dependency
graph stays restricted to the components actually under test.
expected_dep_violations only listed the edges visible when
idf_component_optional_requires was a no-op for the dependency graph.
Under build system v2's DEFERRED mode the call propagates the resolved
dependency back into PRIV_REQUIRES, and the graph also captures
esp_common -> {efuse, bootloader_support, app_update} and esp_system ->
esp_app_format.
Add those entries so the script does not flag them when IDF_BUILD_V2
is set.
main/{esp32s2,esp32c3,esp32s3}/test_panic.c uses WDT registers from
esp_hal_wdt. Declare it explicitly so the build works under cmakev2's
strict component isolation.
Any idf.py invocation could hang indefinitely with no output while
spawning an unbounded chain of "idf.py --version" subprocesses,
eventually exhausting system memory.
During init_cli(), idf.py parses the project's dependencies.lock to
vet trusted component-provided idf_ext.py extensions. If the lock
contains a component whose manifest has an "if: idf_version" clause,
evaluating it calls idf-component-manager's _get_idf_version(). Outside
a CMake build the IDF_VERSION environment variable is not set, so that
function falls back to running "idf.py --version" as a subprocess,
which re-enters init_cli() and recurses without bound.
During a normal CMake build the component manager runs as a subprocess
that already has IDF_VERSION in its environment (see build/config.env),
so the fallback is never reached. The recursion happens only because
idf.py runs component-manager code in-process during its own CLI
startup, outside that context.
Seed IDF_VERSION into os.environ early in init_cli(), before any
dependencies.lock parsing, using the subprocess-free
idf_version_from_cmake() helper. This gives in-process component-manager
code the same IDF_VERSION a CMake build would provide.
When a component's manifest declared a managed dep `<ns>/<name>` and the
project had a local `components/<name>` shadowing it, configure failed
with `IDF: Failed to resolve component '<ns>__<name>'`.
cmakev1 does a project-wide injection so the manager's _choose_component
sees every component name in known_components and rewrites the
namespaced dep to its locally-shadowing short name. cmakev2 invokes the
manager per component with a single-component requirements file, so
known_components has only one entry and the rewrite cannot fire --
`<ns>__<name>` is written verbatim into MANAGED_REQUIRES and the
force-include at component.cmake:995 aborts.
Seed the per-component requirements file with one __COMPONENT_SOURCE
entry per discovered component so handle_project_requirements() builds
the same known_components list cmakev1 produces. The seeded entries are
inert on the cmake side -- the __component_set_property shim ignores
__COMPONENT_SOURCE -- they exist purely to feed the manager's rewrite.
Add a regression test in tools/test_build_system/buildv2/test_component.py.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
feat(esp_tee): Clear out all sensitive buffers explicitly after TEE cryptographic operations
Closes IDF-15671
See merge request espressif/esp-idf!48004
test(ci): re-enable ESP32-H4 in core system test apps
Closes IDF-15602, IDF-15604, IDF-15605, IDF-15606, and IDF-15612
See merge request espressif/esp-idf!48454
