Based on the configuration, set the IDF_TARGET build property. This is
also set by cmakev1 and can be used to easily determine the architecture
for the project.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add embedded source files to the component target sources. This is
intentionally managed in idf_component_include instead of
idf_component_register, allowing even cmakev2 components to set the
component's EMBED_FILES and EMBED_TXTFILES properties. Although it might
be more convenient to call the target_add_binary_data helper function
directly in cmakev2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add a backward-compatible idf_component_register function. This is
necessary to enable existing components to integrate with cmakev2. Note
that, by design, when the configuration is evaluated first, the KCONFIG
and KCONFIG_PROJBUILD options become obsolete, and an error is reported
if non-default configuration file names are specified.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
IDF_BUILD_V2 does not have BUILD_COMPONENTS build property. Therefore,
when IDF_BUILD_V2 is defined, use a generator expressions instead.
The inclusion of esp_eth_netif_glue.c, which relies on the presence of
the esp_netif component, should ideally be managed by a configuration
option. The same applies to the requirements for esp_eth. Currently,
only a basic adjustment has been made to enable the inclusion of esp_eth
in cmakev2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
IDF_BUILD_V2 does not have BUILD_COMPONENTS build property. Therefore,
when IDF_BUILD_V2 is defined, use idf_component_optional_requires and
generator expressions instead. I believe that the one-liner should also
work with IDF_BUILD_V1, but the change is kept separate to clearly show
the difference between IDF_BUILD_V1 and IDF_BUILD_V2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
IDF_BUILD_V2 does not have BUILD_COMPONENTS build property. Therefore,
when IDF_BUILD_V2 is defined, use a generator expressions instead. I
believe that the one-liner should also work with IDF_BUILD_V1, but the
change is kept separate to clearly show the difference between
IDF_BUILD_V1 and IDF_BUILD_V2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add a component interface alias only after the actual target is created,
meaning the component is included. The alias has a well-defined name and
can be used in generator expressions like
`$<$<TARGET_EXISTS:idf::esp_netif>:>` without needing to retrieve the
COMPONENT_ALIAS property.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add binary data into the build target by converting it into a generated
source file, which is then compiled into a binary object as part of the
build process.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The add_deprecated_target_alias function is used by some existing
components, so it should be added to cmakev2 as well.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The file_generate function is used by some existing components, so it
should be added to cmakev2 as well.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The fail_target function is used by some existing components, so it
should be added to cmakev2 as well.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The add_prefix function is used by some existing components, so it
should be added to cmakev2 as well.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The spaces2list function is used by some existing components, so it
should be added to cmakev2 as well.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add the specified component as a dependency only if it is included in
the build. This functions the same way as in cmakev1, but it uses
generator expressions because cmake2 does not maintain the
BUILD_COMPONENTS build property, which would list all components
included in the build.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, this is just a placeholder without implementation. The
implementation will be completed in a subsequent patch set that
integrates ldgen. For now, this is enough for ESP-IDF components can be
included by cmakev2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The __DEPENDENCY_CHAIN was not properly created because the component
names were not added to it. Fix this by maintaining it correctly.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This removes the temporary restriction that only allowed components with
project_components as their source to be evaluated.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This helper function collects component sources within the component's
directory. It will be used by the idf_component_register.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add an optional BASE_DIR option to specify a directory that will serve
as the base directory for evaluating input paths. This can be useful,
for example, when collecting component sources.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The toolchain files are using the remove_duplicated_flags function from
utilities.cmake. However, we want to avoid mixing utilities from cmakev1
and cmakev2. Use `IDF_BUILD_VER_TAG` to include utilities from the
currently used build system version.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add the IDF_BUILD_VER_TAG variables to include the build system version
tag. These variables can be used in files, such as CMake toolchain
files, which are shared between cmakev1 and cmakev2. This allows for the
inclusion of files from the currently running build system version. For
example:
include($ENV{IDF_PATH}/tools/cmake${IDF_BUILD_VER_TAG}/utilities.cmake).
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
It is not possible to add a new sourced file through an environment
variable because kconfcheck has a fixed list of allowed environment
variable names. This issue is tracked under IDF-13847.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The compat.cmake file is intended to include functions necessary for
backward compatibility with cmakev1.
Add the check_expected_tool_version function, which is used by some
project_include.cmake files to verify if the tool's version matches the
installed tool. This functionality is used, for example, by esp_common.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Some idf.py commands, such as menuconfig, use build_target and call
ensure_build_directory, which requires the project_description.json file
to be generated. To enable the use of idf.py commands with the testing
example, call __generate_project_info() to generate the
project_description.json file. This allows you to execute idf.py
menuconfig.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The current config.env.in template cannot be easily extended and shared
between cmakev1 and cmakev2. Although the root Kconfig is shared and
sources COMPONENT_KCONFIGS_EXCLUDED_SOURCE_FILE and
COMPONENT_KCONFIGS_PROJBUILD_EXCLUDED_SOURCE_FILE, these environment
variables cannot be set to empty strings. This issue arises unless we
also adjust cmakev1 and esp-docs, which use prepare_kconfig_files.py, to
properly set COMPONENT_KCONFIGS_EXCLUDED_SOURCE_FILE and
COMPONENT_KCONFIGS_PROJBUILD_EXCLUDED_SOURCE_FILE.
If an environment variable is set to an empty string and sourced in
Kconfig, kconfgen will expand the variable with expandvars(), resulting
in an empty value. This expanded variable is then appended to the root
Kconfig or the currently processed Kconfig directory path, depending on
whether osource or orsource is used, and passed to iglob. The iglog will
return the directory as a result, and when Kconfig attempts to open the
file, it will encounter an error because it is a directory.
To resolve this issue and enable sharing of the root Kconfig file, a new
config_buildv2.env.in template has been added, which includes
environment variables for the excluded components.
For cmakev1, kconfgen will encounter the osource command for
COMPONENT_KCONFIGS_EXCLUDED_SOURCE_FILE. Since this variable is not
defined in config.env.in, expandvars() will return the environment
variable name instead of expanding it, and iglob will not match
anything. Because osource is used for excluded components, the
non-existent file for osource will be skipped.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Pass the environmental variables COMPONENT_KCONFIGS_EXCLUDED_SOURCE_FILE
and COMPONENT_KCONFIGS_PROJBUILD_EXCLUDED_SOURCE_FILE to menuconfig.
This will display the configuration for excluded components under new
menus in menuconfig. Additionally, set the IDF_BUILD_V2 environment
variable to make these new menus visible. The IDF_BUILD_V2 variable is
also passed to all kconfgen commands.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
To generate a complete configuration for all discovered components, we
need to ensure that even kconfig files for the excluded components are
seen by Kconfig. Modify the prepare_kconfig_files.py script to generate
files that list the Kconfig files for excluded components. These files
are sourced in the root Kconfig using the
COMPONENT_KCONFIGS_EXCLUDED_SOURCE_FILE and
COMPONENT_KCONFIGS_PROJBUILD_EXCLUDED_SOURCE_FILE environment variables.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Introduce new configuration menus for components that are not part of
the build. These menus will only be visible if the IDF_BUILD_V2
environment variable is defined and it will be set only in cmakev2. This
enables sharing of the root Kconfig file between cmakev1 and cmakev2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
For backward compatibility, since externalproject_add is used by
project_include.cmake in the bootloader component. The ExternalProject
should probably be included there instead.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
During the initialization of a component in the __init_component
function, store the full path of the project_include.cmake file in the
component's __PROJECT_INCLUDE property, if it exists. Include the
project_include.cmake files for all discovered components at the global
scope within the idf_project_init macro.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Set the global variables IDF_BUILD_V2 and IDF_BUILD_VER, along with the
build properties and environmental variables. These are intended to be
used by components to determine which build system version they are
evaluated under and to make adjustments based on this information.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The current approach involves transparently calling __init_build within
idf_build_library and performing all post-project() initialization
there. The issue with this method is that project_include.cmake files
also need to be included during post-project() initialization, but they
should be included in the global scope. This cannot be achieved within
the __init_build function unless it is converted into a macro. Although
using a macro is a potential solution, it risks causing global scope
pollution. Another complication is the location where project() can be
invoked; it must be explicitly[1] stated in the project's
CMakeLists.txt. This requirement conflicts with our intention to wrap
it within the idf_project_default helper. Given these challenges, it
makes sense to introduce an explicit idf_project_init macro, where all
post-project() initialization occurs, including the inclusion of
project_include.cmake files. While we can still encapsulate this within
idf_project_default, for the plumbing commands (idf_build_library,
idf_build_executable, ...), it will need to be explicitly called after
the project() invocation.
Usage for default project:
cmake_minimum_required(VERSION 3.22)
include($ENV{IDF_PATH}/tools/cmakev2/idf.cmake)
project()
idf_project_default()
Usage for plumbing commands:
cmake_minimum_required(VERSION 3.22)
include($ENV{IDF_PATH}/tools/cmakev2/idf.cmake)
project()
idf_project_init()
idf_build_library()
...
[1] https://cmake.org/cmake/help/latest/command/project.html#usage
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
A new pytest_buildv2_system job has been added to execute selected tests
from the existing test_build_system test suite. Currently, only the
test_non_default_target.py is enabled. The ultimate goal is to run most
of the build system tests with buildv2. This should help ensure
compatibility between IDF build system v1 and v2.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
This marker enables the skipping of tests that, for any reason, cannot
be executed with the IDF build system version 2. It accepts an optional
string argument that explains why the test cannot be run with version 2.
If no explanation is provided, a default message is used. This marker is
used in the `pytest_collection_modifyitems` hook to skip tests marked
with it when the `--buildv2` pytest command line option is used.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The IDF build system v2 should be backward compatible with IDF build
system v1 in most situations. Therefore, it makes sense to reuse the
existing v1 tests and run them for v2 as well. This approach will help
ensure that v2 maintains backward compatibility. Introduce a new
--buildv2 option, which switches the existing tests to use the newly
added buildv2_test_app for v2. The goal is to enable the existing v1
tests incrementally in CI as the v2 implementation progresses.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, the target consistency check with sdkconfig is performed even
if sdkconfig is not present, by comparing the selected target with the
target defined in sdkconfig.defaults. This results in an inconsistency
report when a different target is set in the IDF_TARGET environment
or cmake variable compared to sdkconfig.defaults. The behavior in
cmakev1 is to prioritize IDF_TARGET and ignore values in
sdkconfig.defaults. Perform the consistency check only if the
sdkconfig file exists.
Additionally, skip this consistency check if a set-target action is
taking place, as the old target in sdkconfig is being replaced with a
new value anyway.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The test for guessing the target from the SDKCONFIG_DEFAULTS environment
variable is not cleaning up after itself, leaving the SDKCONFIG_DEFAULTS
environment variable set. The subsequent test performs target guessing
from SDKCONFIG_DEFAULTS passed to cmake with the -D option. The
SDKCONFIG_DEFAULTS environment variable should take precedence over the
SDKCONFIG_DEFAULTS cmake variable. This is correctly handled in cmakev2
, but in cmakev1, the SDKCONFIG_DEFAULTS cmake variable is used even if
the SDKCONFIG_DEFAULTS environment variable is set. This appears to be a
bug or at least an inconsistency in cmakev1.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, this generates a very basic project_description.json file,
allowing idf.py commands that call ensure_build_directory, such as
reconfigure, to be used with cmakev2. The ensure_build_directory
function sets a global context, which is presently used only for hints,
and the project_description.json file is loaded as part of this context.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add two project components, component1 and component2, and verify that
their real targets are created when they are included.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Call idf_component_include for all components requested in the library
and link them into it.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add a core function of the build system, responsible for including the
specified component identified by name, into the build
process.
Currently, the non-project components written in cmakev1 are ignored and
not evaluated with the add_subdirectory command because there are no
shims for the cmakev1 API yet. However, this allows for the evaluation
of project components written using the cmakev2 approach, which is
closer to the native CMake usage.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Gather the compilation options from COMPILE_OPTIONS, C_COMPILE_OPTIONS,
CXX_COMPILE_OPTIONS, and ASM_COMPILE_OPTIONS build properties into a
single list using generator expressions. This list can then be used with
the target_compile_options call.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
