Add a GENERATE_SDKCONFIG build property that controls whether kconfgen
writes the sdkconfig file (--output config) during the configuration
step. It defaults to 1 (enabled).
When building the bootloader as a subproject, the set of components
(and their Kconfig files) differs from the main project. Running
kconfgen with --output config in this context rewrites the main
project's sdkconfig. Even when the content is identical, the timestamp
update causes ninja to detect sdkconfig as newer than build.ninja
outputs (e.g. cmake_install.cmake), triggering an infinite CMake
re-run loop.
Setting GENERATE_SDKCONFIG to 0 in a subproject prevents this,
matching the behaviour of cmakev1's __OUTPUT_SDKCONFIG property.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add the PROJECT_COMPONENTS_SOURCE build property to control how project
components are categorised during component discovery. By default it is
set to "project_components" (priority 3 - highest), preserving the
existing behaviour.
Setting it to "idf_components" (priority 0) before calling
idf_project_init() makes the project's built-in components overridable
by user-supplied components through EXTRA_COMPONENT_DIRS (priority 2).
This is needed for sub-projects like the bootloader, whose built-in
components (e.g. main) are provided by ESP-IDF and should be overridable
by user-supplied components placed in bootloader_components/. The
cmakev1 build system allowed this override because it used a
last-one-wins strategy, but cmakev2 uses strict priority-based component
resolution where project_components always win.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add an optional ALL parameter to idf_build_binary and idf_sign_binary
functions. When specified, the created custom target is included in the
default build target. Without ALL, custom targets created by these
functions are excluded from the default build (add_custom_target
behavior), meaning they won't be built unless explicitly requested or
depended upon by another target in ALL.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add a helper function for printing multi-line post-build messages on a
target. The message lines are joined with newlines, written to a file at
configure time, and printed at build time using a single cmake -E cat
command, replacing the need for repeated cmake -E echo invocations.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add a public API function to check that the bootloader binary does not
overlap the partition table, mirroring the existing idf_check_binary_size
pattern for application binaries.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The KEYFILE argument value was stored in a misspelled variable
"keyfle" instead of "keyfile", causing custom keyfile paths to
be silently ignored.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The commonly required components are configured solely for backward
compatibility with cmakev1. Since the bootloader build explicitly sets
commonly required components, we need to support this feature in cmakev2
as well. Ideally, there should be no commonly required components, and
each component should specify its requirements explicitly.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Some config options, like IDF_TARGET, are present in
sdkconfig.defaults even though they are promptless. The build system
handles them manually and passes them to esp-idf-kconfig via
config.env. However, esp-idf-kconfig reports them like a normal
promptless symbol, which causes confusion.
This commit adds KCONFIG_PROMPTLESS_NO_WARN — a semicolon-separated
list of config option names that, even though promptless, should be
excluded from the report.
Closes https://github.com/espressif/esp-idf/issues/18441
Add a buildv2 test that reconfigures the test app with both GCC and
clang toolchains and asserts that the selected IDF_TOOLCHAIN value
is propagated to sdkconfig. The clang case is skipped when a clang
compiler is not available in PATH.
In the cmakev2 build framework, the selected toolchain was not
consistently propagated to sdkconfig generation. For clang builds,
this produced a configuration that was incompatible with the clang
toolchain and broke compilation.
Ensure the toolchain selection is observed consistently so sdkconfig
and component configuration reflect the intended toolchain for both
GCC and clang builds.
Made-with: Cursor
Verify that setting IDF_COMPONENT_MANAGER=0 skips the component manager
flow entirely and produces a successful build. The test also asserts that
no "Component manager round" messages appear in the output, confirming
the manager loop is not entered.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
When the component manager is disabled via IDF_COMPONENT_MANAGER=0, the
cmakev2 build system still entered the full component manager flow
(__fetch_components_from_registry), which called
__download_managed_component(). That function returned early with
result=0 without creating the expected output file, violating the
post-condition in __download_component_level_managed_components() that
checks result==0 => file exists, causing a fatal error.
Instead of patching the low-level function to write an empty stub file,
this commit properly skips the entire component manager flow when the
manager is disabled:
- Move __init_component_manager() to idf.cmake global initialization
sequence alongside other __init_*() calls, so IDF_COMPONENT_MANAGER
build property is available early.
- Set __SDKCONFIG_ORIG to the real sdkconfig path in __init_kconfig()
as its default value. Previously it was only set inside
__create_sdkconfig_orig_copy() and had a defensive fallback in
__create_base_kconfgen_command(). The default ensures __SDKCONFIG_ORIG
is always valid regardless of whether the component manager runs.
- Guard __create_sdkconfig_orig_copy() with an IDF_COMPONENT_MANAGER
check. The sdkconfig backup exists solely to preserve unknown Kconfig
options from managed components during intermediate kconfgen rounds.
When the manager is disabled, no managed components exist, so the
backup is unnecessary.
- Guard __fetch_components_from_registry() call in project.cmake behind
IDF_COMPONENT_MANAGER == 1. When disabled, only the manifest warning
is issued. No download loop runs, no temp files are created, and no
"Component manager round N..." messages are printed.
- Remove the now-redundant IDF_COMPONENT_MANAGER guard from
__download_managed_component(), since it is only reachable when the
manager is enabled.
Closes https://github.com/espressif/esp-idf/issues/18372
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The cherry-pick in the backport of \!46287 (test/buildv2_pytest_build_v6.0)
dropped the deletion of tools/cmakev2/test/CMakeLists.txt. The original MR
deleted all 15 files from the tools/cmakev2/test/ directory, but the
cherry-pick only captured 14 deletions. This commit removes the missed file.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
In cmake v1, __build_process_project_includes() exports all build
properties as CMake variables before including project_include.cmake
files. cmakev2 was missing this step, causing components like ULP that
reference build properties as CMake variables (e.g. ${SDKCONFIG_HEADER})
to receive empty values.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The cmakev2 kconfig module sets sdkconfig output paths using internal
property names (__SDKCONFIG_HEADER, __SDKCONFIG_CMAKE, etc.), but
components like ULP read the public names (SDKCONFIG_HEADER,
SDKCONFIG_CMAKE). This results in empty values being passed to the ULP
sub-project, causing its CMake configure step to fail.
Add public aliases matching the cmake v1 property names for backward
compatibility.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This commit introduces a new build property, __OPTIONAL_REQUIRES_MODE,
and uses it to either defer or link immediately, optional requirements
to components that request such linkage via the
idf_component_optional_requires() function in build system v2. The
DEFERRED mode is intended for single-binary projects where in the linking
of optional components happens after the library target is created the
dependency graph is available to the build system, thereby allowing it to
behave like the v1 version of the function.
Introduce a callback mechanism that lets components register CMake
functions to be called at specific points in the build lifecycle.
Currently, this framework only supports registering callbacks to be
called after the executable target is created, i.e, the POST_ELF phase
of the build but before the binary target is created.
