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>
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>
Set the LINKER_TYPE build property. Different linkers may have varying
options, so it's important to identify the linker type to configure the
options correctly. Currently, LINKER_TYPE is used to set the appropriate
linker options for linking the entire archive, which differs between the
GNU and Apple linkers when building on the host.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Simple test for PROJECT_NAME and PROJECT_VER build properties to ensure
they are set according to the values provided in the project() call.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Currently, only the value stored in CMake's cache is considered when
setting the default value. Allow regular variables as well, which may be
set in the project's CMakeLists.txt file.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Initialize the PROJECT_VER build property based on the following
precedence.
1. The PROJECT_VER environment or CMake variable.
2. The version.txt file located in the top-level project directory.
3. The VERSION argument, if provided, in the project() macro.
4. The output of git describe if the project is within a Git repository.
5. Defaults to 1 if none of the above conditions are met.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Add the __init_build_configuration() function to set all C, CXX, ASM,
and linker options, along with compilation defines, in a single
location. In cmakev1, these settings are scattered across multiple
places and it seems logical to group them together.
This function is called from the __init_build(), which is invoked after
project(). This sequence is necessary because some options depend on the
CMake information about the compiler, which is only available once the
toolchain has been initialized in project().
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Most of the global settings are configured in idf.cmake, but certain
elements can only be initialized after the project() function is called
and the toolchain is set up. For example, this includes the compilation
options, which may depend on identified compiler or the project name and
version set in the project() call. The __init_build function is called
at the beginning of the idf_build_library() function, meaning it should
be executed after the project() call. It ensures that initialization
occurs only once by setting the __BUILD_INITIALIZED build property.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Initialize submodules that are not yet initialized, and issue a warning
for submodules that do not match the recorded hash in the git tree.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
When working with command output, it is sometimes necessary to handle it
line by line. Add a `__split` helper function that can split an input
string based on a specified separator, which defaults to a newline, and
store the results in a list. This function also offers modifiers to
strip whitespace and remove empty entries.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Initialize the IDF_VER build property using the version.txt file, or use
git-describe. If neither is available, fall back to the value of the
IDF_VERSION environment variable.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The Git tool will be used in various parts of the build system, such as
retrieving the IDF version using git-describe or checking submodules.
Similar to the Python interpreter, add an initialization function to
identify the Git executable.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The following functions are added to tools/cmakev2/kconfig.cmake:
- __generate_kconfig_outputs(): Generates Kconfig output files.
- __create_base_kconfgen_command(): Creates command for running
kconfgen.
- __run_kconfgen(): Invokes kconfgen tool.
The following functions are added to tools/cmakev2/kconfig.cmake:
- __setup_kconfig_environment(): Creates Kconfig environment for Kconfig
output generation.
- __get_init_config_version(): Fetch ESP-IDF version and set the
environment variable.
- __create_config_env_file(): Create the config.env file for kconfgen.
The following functions are added to tools/cmakev2/kconfig.cmake:
- __collect_kconfig_files_from_components(): Collect Kconfig files from
components.
- __collect_kconfig_files_from_bootloader_components(): Collect Kconfig
files from bootloader components.
- __collect_kconfig_files_from_directory(): Collect Kconfig files from
a directory.
This commit adds the tools/cmakev2/kconfig.cmake file for Kconfig
processing. The file provides the following functions:
- __init_kconfig(): Placeholder to initialize Kconfig build properties,
collect kconfig files and generate the initial sdkconfig.
- __generate_sdkconfig(): Placeholder to generate sdkconfig output files.
Add idf_build_library function and enable setting and getting its
properties. This lays the groundwork for future initialization that
needs to occur after the project() call, such as determining compilation
options and others.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
The `idf_build_(set|get)_property` and
`idf_component_(set|get)_property` functions share a lot of similar
code. Move these common parts into new `__(set|get)_property` helper
functions. With the upcoming `idf_build_library` API function, we might
need to add properties for the interface target created for the library,
which would otherwise lead to yet another code duplication for setting
and getting library interface properties.
Update the current implementations of `idf_build_(set|get)_property` and
`idf_component_(set|get)_property` to utilize these new helper
functions.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Determine the IDF_TOOLCHAIN from the following sources in this order:
environmental variable and CMake cache variable. Ensure there are no
inconsistencies between the values set in these different locations.
Set the IDF_TOOLCHAIN and IDF_TOOLCHAIN_FILE build properties. Also,
configure the IDF_TOOLCHAIN CMake cache variable and set the
CMAKE_TOOLCHAIN_FILE global variable.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Determine the IDF_TARGET from the following sources in this order:
environmental variable, CMake cache variable, and sdkconfig files.
Ensure there are no inconsistencies between the values set in these
different locations.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Based on the environmental variables, CMake cache variables, or default
values, set the DKCONFIG and SDKCONFIG_DEFAULTS build properties.
Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Frantisek Hrbata
Sudeep Mohanty