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.
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
The build system currently suffers from a bug where custom configuration
settings are lost when the component manager is invoked multiple times.
During an initial reconfigure or set-target command, the component
manager may return no managed components. Because the build system lacks
the Kconfig definitions for these components at this stage, it
automatically prunes any related configuration symbols—specifically
those defined in managed component Kconfig files—from the sdkconfig
file. By the time the component manager finishes downloading the
dependencies in a subsequent run, these original settings have already
been overwritten and discarded because they were previously unrecognized
by the build system.
To resolve this, the generation of the final sdkconfig should be
deferred until all component manager resolution cycles are complete. We
need to ensure that the build system does not treat missing Kconfig
definitions as invalid until the full dependency graph is loaded. A
potential fix involves using a temporary configuration file for
intermediate component manager passes to prevent the main sdkconfig from
being prematurely scrubbed of valid user settings that belong to
yet-to-be-resolved components.
Edit:
Added cleanup of sdkconfig.cm file and comments
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Edited by: Daniel Paul <daniel.paul@espressif.com>
