2019-04-06 15:08:09 +02:00
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
2021-12-16 17:13:54 +01:00
|
|
|
include_guard(GLOBAL)
|
|
|
|
|
|
|
|
include(extensions)
|
|
|
|
include(python)
|
|
|
|
|
2021-12-15 15:00:06 +01:00
|
|
|
# autoconf.h is generated by Kconfig and placed in <build>/zephyr/include/generated/autoconf.h.
|
|
|
|
# A project may request a custom location by setting AUTOCONF_H explicitly before
|
|
|
|
# calling 'find_package(Zephyr)' or loading this module.
|
|
|
|
set_ifndef(AUTOCONF_H ${PROJECT_BINARY_DIR}/include/generated/autoconf.h)
|
|
|
|
# Re-configure (Re-execute all CMakeLists.txt code) when autoconf.h changes
|
|
|
|
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${AUTOCONF_H})
|
|
|
|
|
2017-10-27 15:43:34 +02:00
|
|
|
# Folders needed for conf/mconf files (kconfig has no method of redirecting all output files).
|
2018-03-26 17:11:00 +02:00
|
|
|
# conf/mconf needs to be run from a different directory because of: GH-3408
|
2017-10-27 15:43:34 +02:00
|
|
|
file(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/kconfig/include/generated)
|
|
|
|
file(MAKE_DIRECTORY ${PROJECT_BINARY_DIR}/kconfig/include/config)
|
|
|
|
|
2021-11-27 11:50:37 +01:00
|
|
|
set_ifndef(KCONFIG_NAMESPACE "CONFIG")
|
|
|
|
|
2022-08-05 10:13:58 +02:00
|
|
|
set_ifndef(KCONFIG_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/Kconfig)
|
|
|
|
file(MAKE_DIRECTORY ${KCONFIG_BINARY_DIR})
|
|
|
|
|
2022-09-14 22:23:15 +02:00
|
|
|
if(HWMv1)
|
|
|
|
# Support multiple SOC_ROOT
|
|
|
|
file(MAKE_DIRECTORY ${KCONFIG_BINARY_DIR}/soc)
|
|
|
|
set(kconfig_soc_root ${BOARD_ROOT})
|
|
|
|
list(REMOVE_ITEM kconfig_soc_root ${ZEPHYR_BASE})
|
|
|
|
set(soc_defconfig_file ${KCONFIG_BINARY_DIR}/soc/Kconfig.defconfig)
|
|
|
|
|
|
|
|
# This loads Zephyr base SoC root defconfigs
|
|
|
|
file(WRITE ${soc_defconfig_file} "osource \"soc/soc_legacy/$(ARCH)/*/Kconfig.defconfig\"\n")
|
|
|
|
|
|
|
|
set(OPERATION WRITE)
|
|
|
|
foreach(root ${kconfig_soc_root})
|
|
|
|
file(APPEND ${soc_defconfig_file}
|
2024-03-05 09:29:48 +01:00
|
|
|
"osource \"${root}/soc/$(ARCH)/*/Kconfig.defconfig\"\n")
|
2022-09-14 22:23:15 +02:00
|
|
|
file(${OPERATION} ${KCONFIG_BINARY_DIR}/soc/Kconfig.soc.choice
|
2024-03-05 09:29:48 +01:00
|
|
|
"osource \"${root}/soc/$(ARCH)/*/Kconfig.soc\"\n"
|
2022-09-14 22:23:15 +02:00
|
|
|
)
|
|
|
|
file(${OPERATION} ${KCONFIG_BINARY_DIR}/soc/Kconfig.soc.arch
|
2024-03-05 09:29:48 +01:00
|
|
|
"osource \"${root}/soc/$(ARCH)/Kconfig\"\n"
|
|
|
|
"osource \"${root}/soc/$(ARCH)/*/Kconfig\"\n"
|
2022-09-14 22:23:15 +02:00
|
|
|
)
|
|
|
|
set(OPERATION APPEND)
|
|
|
|
endforeach()
|
|
|
|
endif()
|
2020-07-06 12:53:39 +02:00
|
|
|
|
2021-06-02 08:47:21 +02:00
|
|
|
# Support multiple shields in BOARD_ROOT, remove ZEPHYR_BASE as that is always sourced.
|
|
|
|
set(kconfig_board_root ${BOARD_ROOT})
|
|
|
|
list(REMOVE_ITEM kconfig_board_root ${ZEPHYR_BASE})
|
2020-10-27 11:08:28 +01:00
|
|
|
set(OPERATION WRITE)
|
2021-06-02 08:47:21 +02:00
|
|
|
foreach(root ${kconfig_board_root})
|
2020-10-27 11:08:28 +01:00
|
|
|
file(${OPERATION} ${KCONFIG_BINARY_DIR}/Kconfig.shield.defconfig
|
|
|
|
"osource \"${root}/boards/shields/*/Kconfig.defconfig\"\n"
|
|
|
|
)
|
|
|
|
file(${OPERATION} ${KCONFIG_BINARY_DIR}/Kconfig.shield
|
|
|
|
"osource \"${root}/boards/shields/*/Kconfig.shield\"\n"
|
|
|
|
)
|
|
|
|
set(OPERATION APPEND)
|
|
|
|
endforeach()
|
|
|
|
|
2018-09-21 14:36:58 +02:00
|
|
|
if(KCONFIG_ROOT)
|
2023-05-17 10:31:32 +02:00
|
|
|
# Perform any variable substitutions if they are present
|
|
|
|
string(CONFIGURE "${KCONFIG_ROOT}" KCONFIG_ROOT)
|
|
|
|
|
cmake: ensure consistent behavior between x_ROOT settings
Fixes: #23825
Today, BOARD, SOC, ARCH, DTS, KCONFIG, and TOOLCHAIN_ROOT can be
specified by users or through other CMake files.
It is not clear if relative paths are permitted and/or from where a
relative path is constructed.
Inside CMake, it is very easy to specify `${ZEPHYR_BASE}`,
`${CMAKE_CURRENT_SOURCE_DIR}`, or similar, thus there is no reason to
use relative path inside CMake, as it easy can lead to discussion on
relative to what.
For users manually invoking CMake using, `cmake ... <app-dir>` it is
nice to have to possibility to specify a relative path.
For this purpose, relative path are considered relative to the
`APPLICATION_SOURCE_DIR`.
This commit updates:
- BOARD_ROOT
- SOC_ROOT
- ARCH_ROOT
- DTS_ROOT
- KCONFIG_ROOT
- TOOLCHAIN_ROOT
to allow paths relative to `APPLICATION_SOURCE_DIR` when specified with
`-D<type>_ROOT=<relative-path>`
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-09-08 14:07:00 +02:00
|
|
|
zephyr_file(APPLICATION_ROOT KCONFIG_ROOT)
|
2018-09-21 14:36:58 +02:00
|
|
|
# KCONFIG_ROOT has either been specified as a CMake variable or is
|
|
|
|
# already in the CMakeCache.txt. This has precedence.
|
|
|
|
elseif(EXISTS ${APPLICATION_SOURCE_DIR}/Kconfig)
|
|
|
|
set(KCONFIG_ROOT ${APPLICATION_SOURCE_DIR}/Kconfig)
|
|
|
|
else()
|
|
|
|
set(KCONFIG_ROOT ${ZEPHYR_BASE}/Kconfig)
|
|
|
|
endif()
|
2017-10-27 15:43:34 +02:00
|
|
|
|
2022-09-14 22:23:15 +02:00
|
|
|
if(NOT DEFINED BOARD_DEFCONFIG)
|
|
|
|
zephyr_file(CONF_FILES ${BOARD_DIR} DEFCONFIG BOARD_DEFCONFIG)
|
2023-01-11 15:58:16 +01:00
|
|
|
endif()
|
2022-09-14 22:23:15 +02:00
|
|
|
|
|
|
|
if(DEFINED BOARD_REVISION)
|
|
|
|
zephyr_build_string(config_board_string
|
|
|
|
BOARD ${BOARD}
|
2024-03-19 15:26:59 +01:00
|
|
|
BOARD_QUALIFIERS ${BOARD_QUALIFIERS}
|
2022-09-14 22:23:15 +02:00
|
|
|
BOARD_REVISION ${BOARD_REVISION}
|
|
|
|
)
|
|
|
|
set(board_rev_file ${config_board_string})
|
|
|
|
if(EXISTS ${BOARD_DIR}/${board_rev_file}.conf)
|
|
|
|
message(DEPRECATION "Use of '${board_rev_file}.conf' is deprecated, please switch to '${board_rev_file}_defconfig'")
|
|
|
|
set_ifndef(BOARD_REVISION_CONFIG ${BOARD_DIR}/${board_rev_file}.conf)
|
|
|
|
endif()
|
|
|
|
endif()
|
|
|
|
|
2019-02-20 17:42:09 +01:00
|
|
|
set(DOTCONFIG ${PROJECT_BINARY_DIR}/.config)
|
2019-02-20 17:49:46 +01:00
|
|
|
set(PARSED_KCONFIG_SOURCES_TXT ${PROJECT_BINARY_DIR}/kconfig/sources.txt)
|
2017-10-27 15:43:34 +02:00
|
|
|
|
|
|
|
if(CONF_FILE)
|
2022-01-21 19:58:17 +01:00
|
|
|
string(CONFIGURE "${CONF_FILE}" CONF_FILE_EXPANDED)
|
|
|
|
string(REPLACE " " ";" CONF_FILE_AS_LIST "${CONF_FILE_EXPANDED}")
|
2017-10-27 15:43:34 +02:00
|
|
|
endif()
|
|
|
|
|
2023-05-17 12:46:24 +02:00
|
|
|
if(EXTRA_CONF_FILE)
|
|
|
|
string(CONFIGURE "${EXTRA_CONF_FILE}" EXTRA_CONF_FILE_EXPANDED)
|
|
|
|
string(REPLACE " " ";" EXTRA_CONF_FILE_AS_LIST "${EXTRA_CONF_FILE_EXPANDED}")
|
2019-02-12 19:59:08 +01:00
|
|
|
endif()
|
|
|
|
|
2023-12-05 11:10:59 +01:00
|
|
|
zephyr_file(CONF_FILES ${BOARD_EXTENSION_DIRS} KCONF board_extension_conf_files SUFFIX ${FILE_SUFFIX})
|
2020-11-11 10:10:41 +01:00
|
|
|
|
2019-09-26 17:45:47 +02:00
|
|
|
# DTS_ROOT_BINDINGS is a semicolon separated list, this causes
|
|
|
|
# problems when invoking kconfig_target since semicolon is a special
|
|
|
|
# character in the C shell, so we make it into a question-mark
|
|
|
|
# separated list instead.
|
|
|
|
string(REPLACE ";" "?" DTS_ROOT_BINDINGS "${DTS_ROOT_BINDINGS}")
|
|
|
|
|
2020-08-25 14:07:35 +02:00
|
|
|
# Export each `ZEPHYR_<module>_MODULE_DIR` to Kconfig.
|
|
|
|
# This allows Kconfig files to refer relative from a modules root as:
|
|
|
|
# source "$(ZEPHYR_FOO_MODULE_DIR)/Kconfig"
|
|
|
|
foreach(module_name ${ZEPHYR_MODULE_NAMES})
|
2021-01-19 12:01:38 +01:00
|
|
|
zephyr_string(SANITIZE TOUPPER MODULE_NAME_UPPER ${module_name})
|
2020-08-25 14:07:35 +02:00
|
|
|
list(APPEND
|
|
|
|
ZEPHYR_KCONFIG_MODULES_DIR
|
|
|
|
"ZEPHYR_${MODULE_NAME_UPPER}_MODULE_DIR=${ZEPHYR_${MODULE_NAME_UPPER}_MODULE_DIR}"
|
|
|
|
)
|
2020-12-17 11:27:42 +01:00
|
|
|
|
|
|
|
if(ZEPHYR_${MODULE_NAME_UPPER}_KCONFIG)
|
|
|
|
list(APPEND
|
|
|
|
ZEPHYR_KCONFIG_MODULES_DIR
|
|
|
|
"ZEPHYR_${MODULE_NAME_UPPER}_KCONFIG=${ZEPHYR_${MODULE_NAME_UPPER}_KCONFIG}"
|
|
|
|
)
|
|
|
|
endif()
|
2020-08-25 14:07:35 +02:00
|
|
|
endforeach()
|
|
|
|
|
2020-08-25 11:02:45 +02:00
|
|
|
# A list of common environment settings used when invoking Kconfig during CMake
|
|
|
|
# configure time or menuconfig and related build target.
|
2021-01-26 20:29:03 +01:00
|
|
|
string(REPLACE ";" "\\\;" SHIELD_AS_LIST_ESCAPED "${SHIELD_AS_LIST}")
|
2021-12-02 07:33:19 +01:00
|
|
|
# cmake commands are escaped differently
|
|
|
|
string(REPLACE ";" "\\;" SHIELD_AS_LIST_ESCAPED_COMMAND "${SHIELD_AS_LIST}")
|
2021-01-26 20:29:03 +01:00
|
|
|
|
2023-02-11 07:01:55 +01:00
|
|
|
if(TOOLCHAIN_HAS_NEWLIB)
|
|
|
|
set(_local_TOOLCHAIN_HAS_NEWLIB y)
|
|
|
|
else()
|
|
|
|
set(_local_TOOLCHAIN_HAS_NEWLIB n)
|
|
|
|
endif()
|
|
|
|
|
2023-07-25 18:23:41 +02:00
|
|
|
if(TOOLCHAIN_HAS_PICOLIBC)
|
|
|
|
set(_local_TOOLCHAIN_HAS_PICOLIBC y)
|
|
|
|
else()
|
|
|
|
set(_local_TOOLCHAIN_HAS_PICOLIBC n)
|
|
|
|
endif()
|
|
|
|
|
2020-08-25 11:02:45 +02:00
|
|
|
set(COMMON_KCONFIG_ENV_SETTINGS
|
|
|
|
PYTHON_EXECUTABLE=${PYTHON_EXECUTABLE}
|
|
|
|
srctree=${ZEPHYR_BASE}
|
|
|
|
KERNELVERSION=${KERNELVERSION}
|
2023-03-23 11:02:49 +01:00
|
|
|
APPVERSION=${APP_VERSION_STRING}
|
2024-01-26 12:19:29 +01:00
|
|
|
APP_VERSION_EXTENDED_STRING=${APP_VERSION_EXTENDED_STRING}
|
|
|
|
APP_VERSION_TWEAK_STRING=${APP_VERSION_TWEAK_STRING}
|
2021-11-27 11:50:37 +01:00
|
|
|
CONFIG_=${KCONFIG_NAMESPACE}_
|
2020-08-25 11:02:45 +02:00
|
|
|
KCONFIG_CONFIG=${DOTCONFIG}
|
|
|
|
BOARD_DIR=${BOARD_DIR}
|
2022-09-14 22:23:15 +02:00
|
|
|
BOARD=${BOARD}
|
2022-04-07 20:21:18 +02:00
|
|
|
BOARD_REVISION=${BOARD_REVISION}
|
2024-03-19 15:26:59 +01:00
|
|
|
BOARD_QUALIFIERS=${BOARD_QUALIFIERS}
|
2022-09-14 22:23:15 +02:00
|
|
|
HWM_SCHEME=${HWM}
|
2020-08-25 11:02:45 +02:00
|
|
|
KCONFIG_BINARY_DIR=${KCONFIG_BINARY_DIR}
|
2023-03-23 11:02:49 +01:00
|
|
|
APPLICATION_SOURCE_DIR=${APPLICATION_SOURCE_DIR}
|
2022-03-03 10:56:29 +01:00
|
|
|
ZEPHYR_TOOLCHAIN_VARIANT=${ZEPHYR_TOOLCHAIN_VARIANT}
|
2020-08-25 11:02:45 +02:00
|
|
|
TOOLCHAIN_KCONFIG_DIR=${TOOLCHAIN_KCONFIG_DIR}
|
2023-02-11 07:01:55 +01:00
|
|
|
TOOLCHAIN_HAS_NEWLIB=${_local_TOOLCHAIN_HAS_NEWLIB}
|
2023-07-25 18:23:41 +02:00
|
|
|
TOOLCHAIN_HAS_PICOLIBC=${_local_TOOLCHAIN_HAS_PICOLIBC}
|
2020-08-25 11:02:45 +02:00
|
|
|
EDT_PICKLE=${EDT_PICKLE}
|
2020-08-25 14:07:35 +02:00
|
|
|
# Export all Zephyr modules to Kconfig
|
|
|
|
${ZEPHYR_KCONFIG_MODULES_DIR}
|
2020-08-25 11:02:45 +02:00
|
|
|
)
|
2018-01-09 14:12:07 +01:00
|
|
|
|
2022-09-14 22:23:15 +02:00
|
|
|
if(HWMv1)
|
|
|
|
list(APPEND COMMON_KCONFIG_ENV_SETTINGS
|
|
|
|
ARCH=${ARCH}
|
|
|
|
ARCH_DIR=${ARCH_DIR}
|
|
|
|
)
|
|
|
|
else()
|
|
|
|
# For HWMv2 we should in future generate a Kconfig.arch.v2 which instead
|
|
|
|
# glob-sources all arch roots, but for Zephyr itself, the current approach is
|
|
|
|
# sufficient.
|
|
|
|
list(APPEND COMMON_KCONFIG_ENV_SETTINGS
|
|
|
|
ARCH=*
|
|
|
|
ARCH_DIR=${ZEPHYR_BASE}/arch
|
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
2019-02-20 13:39:58 +01:00
|
|
|
# Allow out-of-tree users to add their own Kconfig python frontend
|
|
|
|
# targets by appending targets to the CMake list
|
|
|
|
# 'EXTRA_KCONFIG_TARGETS' and setting variables named
|
|
|
|
# 'EXTRA_KCONFIG_TARGET_COMMAND_FOR_<target>'
|
|
|
|
#
|
|
|
|
# e.g.
|
|
|
|
# cmake -DEXTRA_KCONFIG_TARGETS=cli
|
|
|
|
# -DEXTRA_KCONFIG_TARGET_COMMAND_FOR_cli=cli_kconfig_frontend.py
|
|
|
|
|
|
|
|
set(EXTRA_KCONFIG_TARGET_COMMAND_FOR_menuconfig
|
|
|
|
${ZEPHYR_BASE}/scripts/kconfig/menuconfig.py
|
2018-05-02 04:16:28 +02:00
|
|
|
)
|
2017-10-27 15:43:34 +02:00
|
|
|
|
2019-05-06 14:23:47 +02:00
|
|
|
set(EXTRA_KCONFIG_TARGET_COMMAND_FOR_guiconfig
|
|
|
|
${ZEPHYR_BASE}/scripts/kconfig/guiconfig.py
|
|
|
|
)
|
|
|
|
|
2019-10-28 17:28:40 +01:00
|
|
|
set(EXTRA_KCONFIG_TARGET_COMMAND_FOR_hardenconfig
|
|
|
|
${ZEPHYR_BASE}/scripts/kconfig/hardenconfig.py
|
|
|
|
)
|
|
|
|
|
2021-11-27 11:58:00 +01:00
|
|
|
set_ifndef(KCONFIG_TARGETS menuconfig guiconfig hardenconfig)
|
|
|
|
|
2019-02-20 13:39:58 +01:00
|
|
|
foreach(kconfig_target
|
2021-11-27 11:58:00 +01:00
|
|
|
${KCONFIG_TARGETS}
|
2019-02-20 13:39:58 +01:00
|
|
|
${EXTRA_KCONFIG_TARGETS}
|
|
|
|
)
|
|
|
|
add_custom_target(
|
|
|
|
${kconfig_target}
|
|
|
|
${CMAKE_COMMAND} -E env
|
2019-04-12 12:17:14 +02:00
|
|
|
ZEPHYR_BASE=${ZEPHYR_BASE}
|
2020-08-25 11:02:45 +02:00
|
|
|
${COMMON_KCONFIG_ENV_SETTINGS}
|
2021-01-26 20:29:03 +01:00
|
|
|
"SHIELD_AS_LIST=${SHIELD_AS_LIST_ESCAPED}"
|
2019-08-28 16:30:23 +02:00
|
|
|
DTS_POST_CPP=${DTS_POST_CPP}
|
|
|
|
DTS_ROOT_BINDINGS=${DTS_ROOT_BINDINGS}
|
2019-02-20 13:39:58 +01:00
|
|
|
${PYTHON_EXECUTABLE}
|
|
|
|
${EXTRA_KCONFIG_TARGET_COMMAND_FOR_${kconfig_target}}
|
|
|
|
${KCONFIG_ROOT}
|
|
|
|
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/kconfig
|
|
|
|
USES_TERMINAL
|
2020-08-25 11:02:45 +02:00
|
|
|
COMMAND_EXPAND_LISTS
|
2019-02-20 13:39:58 +01:00
|
|
|
)
|
|
|
|
endforeach()
|
|
|
|
|
2018-06-18 16:51:43 +02:00
|
|
|
# Support assigning Kconfig symbols on the command-line with CMake
|
2021-11-27 11:50:37 +01:00
|
|
|
# cache variables prefixed according to the Kconfig namespace.
|
|
|
|
# This feature is experimental and undocumented until it has undergone more
|
2018-06-18 16:51:43 +02:00
|
|
|
# user-testing.
|
|
|
|
unset(EXTRA_KCONFIG_OPTIONS)
|
2022-08-18 16:02:50 +02:00
|
|
|
if(SYSBUILD)
|
|
|
|
get_property(sysbuild_variable_names TARGET sysbuild_cache PROPERTY "SYSBUILD_CACHE:VARIABLES")
|
|
|
|
zephyr_get(SYSBUILD_MAIN_APP)
|
|
|
|
zephyr_get(SYSBUILD_NAME)
|
|
|
|
|
|
|
|
foreach (name ${sysbuild_variable_names})
|
|
|
|
if("${name}" MATCHES "^${SYSBUILD_NAME}_${KCONFIG_NAMESPACE}_")
|
|
|
|
string(REGEX REPLACE "^${SYSBUILD_NAME}_" "" org_name ${name})
|
|
|
|
get_property(${org_name} TARGET sysbuild_cache PROPERTY ${name})
|
|
|
|
list(APPEND cache_variable_names ${org_name})
|
|
|
|
elseif(SYSBUILD_MAIN_APP AND "${name}" MATCHES "^${KCONFIG_NAMESPACE}_")
|
|
|
|
get_property(${name} TARGET sysbuild_cache PROPERTY ${name})
|
|
|
|
list(APPEND cache_variable_names ${name})
|
|
|
|
endif()
|
|
|
|
endforeach()
|
|
|
|
else()
|
|
|
|
get_cmake_property(cache_variable_names CACHE_VARIABLES)
|
cmake: kconfig: Keep symbol names sorted in EXTRA_KCONFIG_OPTIONS
This makes checksum calculation over Kconfig fragments more consistent,
which prevents writing a new `.config` when nothing really changes.
To explain this, consider the following sequence:
1. west build . -DCONFIG_XXXX=y -DCONFIG_YYYY=y
2. west build . -DCONFIG_YYYY=y
3. west build . -DCONFIG_XXXX=y
At (1), we set new values for XXXX and YYYY, so the `.config` changes.
At (2), we set a value for YYYY, but it's the same value as before, so
the `.config` doesn't get overwritten.
At (3), we set a value for XXXX, but it's the same value as before, so
the `.config` shouldn't get overwritten... but it does. What happened?
The reason is that the generated `extra_kconfig_options.conf` fragment,
which is included in the checksum calculation, was being populated using
two sets of CMake cache variables:
- past assignments, prefixed with `CLI_${KCONFIG_NAMESPACE}_`.
- new assignments, prefixed with just `${KCONFIG_NAMESPACE}_`.
Usually, past assignments would appear before new assignments, because
the default `${KCONFIG_NAMESPACE}` is CONFIG, which goes after CLI in
alphabetical order. As a result, the contents of EXTRA_KCONFIG_OPTIONS
at (1) and (2):
CONFIG_XXXX=y
CONFIG_YYYY=y
were not identical to its contents at (3):
CONFIG_YYYY=y
CONFIG_XXXX=y
resulting in a different checksum.
This is resolved by stripping out the CLI prefix first, then effectively
"mergesorting" the past and new assignments, before starting to populate
EXTRA_KCONFIG_OPTIONS.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
2023-07-03 02:05:06 +02:00
|
|
|
list(FILTER cache_variable_names INCLUDE REGEX "^(CLI_)?${KCONFIG_NAMESPACE}_")
|
|
|
|
list(TRANSFORM cache_variable_names REPLACE "^CLI_" "")
|
|
|
|
list(REMOVE_DUPLICATES cache_variable_names)
|
2022-08-18 16:02:50 +02:00
|
|
|
endif()
|
|
|
|
|
cmake: kconfig: Keep symbol names sorted in EXTRA_KCONFIG_OPTIONS
This makes checksum calculation over Kconfig fragments more consistent,
which prevents writing a new `.config` when nothing really changes.
To explain this, consider the following sequence:
1. west build . -DCONFIG_XXXX=y -DCONFIG_YYYY=y
2. west build . -DCONFIG_YYYY=y
3. west build . -DCONFIG_XXXX=y
At (1), we set new values for XXXX and YYYY, so the `.config` changes.
At (2), we set a value for YYYY, but it's the same value as before, so
the `.config` doesn't get overwritten.
At (3), we set a value for XXXX, but it's the same value as before, so
the `.config` shouldn't get overwritten... but it does. What happened?
The reason is that the generated `extra_kconfig_options.conf` fragment,
which is included in the checksum calculation, was being populated using
two sets of CMake cache variables:
- past assignments, prefixed with `CLI_${KCONFIG_NAMESPACE}_`.
- new assignments, prefixed with just `${KCONFIG_NAMESPACE}_`.
Usually, past assignments would appear before new assignments, because
the default `${KCONFIG_NAMESPACE}` is CONFIG, which goes after CLI in
alphabetical order. As a result, the contents of EXTRA_KCONFIG_OPTIONS
at (1) and (2):
CONFIG_XXXX=y
CONFIG_YYYY=y
were not identical to its contents at (3):
CONFIG_YYYY=y
CONFIG_XXXX=y
resulting in a different checksum.
This is resolved by stripping out the CLI prefix first, then effectively
"mergesorting" the past and new assignments, before starting to populate
EXTRA_KCONFIG_OPTIONS.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
2023-07-03 02:05:06 +02:00
|
|
|
# Sorting the variable names will make checksum calculation more stable.
|
|
|
|
list(SORT cache_variable_names)
|
2018-06-18 16:51:43 +02:00
|
|
|
foreach (name ${cache_variable_names})
|
cmake: kconfig: Keep symbol names sorted in EXTRA_KCONFIG_OPTIONS
This makes checksum calculation over Kconfig fragments more consistent,
which prevents writing a new `.config` when nothing really changes.
To explain this, consider the following sequence:
1. west build . -DCONFIG_XXXX=y -DCONFIG_YYYY=y
2. west build . -DCONFIG_YYYY=y
3. west build . -DCONFIG_XXXX=y
At (1), we set new values for XXXX and YYYY, so the `.config` changes.
At (2), we set a value for YYYY, but it's the same value as before, so
the `.config` doesn't get overwritten.
At (3), we set a value for XXXX, but it's the same value as before, so
the `.config` shouldn't get overwritten... but it does. What happened?
The reason is that the generated `extra_kconfig_options.conf` fragment,
which is included in the checksum calculation, was being populated using
two sets of CMake cache variables:
- past assignments, prefixed with `CLI_${KCONFIG_NAMESPACE}_`.
- new assignments, prefixed with just `${KCONFIG_NAMESPACE}_`.
Usually, past assignments would appear before new assignments, because
the default `${KCONFIG_NAMESPACE}` is CONFIG, which goes after CLI in
alphabetical order. As a result, the contents of EXTRA_KCONFIG_OPTIONS
at (1) and (2):
CONFIG_XXXX=y
CONFIG_YYYY=y
were not identical to its contents at (3):
CONFIG_YYYY=y
CONFIG_XXXX=y
resulting in a different checksum.
This is resolved by stripping out the CLI prefix first, then effectively
"mergesorting" the past and new assignments, before starting to populate
EXTRA_KCONFIG_OPTIONS.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
2023-07-03 02:05:06 +02:00
|
|
|
if(DEFINED ${name})
|
2021-11-27 11:50:37 +01:00
|
|
|
# When a cache variable starts with the 'KCONFIG_NAMESPACE' value, it is
|
|
|
|
# assumed to be a Kconfig symbol assignment from the CMake command line.
|
2018-06-18 16:51:43 +02:00
|
|
|
set(EXTRA_KCONFIG_OPTIONS
|
|
|
|
"${EXTRA_KCONFIG_OPTIONS}\n${name}=${${name}}"
|
|
|
|
)
|
cmake: kconfig: preserved quotes for Kconfig string values
Fixes: #48950
Kconfig requires quoted strings in its configuration files, like this:
> CONFIG_A_STRING="foo bar"
But CMake requires expects that strings are without additional qoutes,
and therefore qoutes are stripped when loading Kconfig config filers
into CMake.
This is particular important when the string in Kconfig is a path to a
file. In this case, not stripping the quotes leads to an error as the
file cannot be found.
When users pass a string to Kconfig through CMake, they are expected to
pass it so that qoutes are correct seen from Kconfig, that is:
> cmake -DCONFIG_A_STRING=\"foo bar\"
In CMake, those qoutes are written as-is to Kconfig extra config file,
and then removed in the CMake cache.
After Kconfig processing, the Kconfig settings are read back to CMake
but without quotes. Settings that was passed through the CMake cache,
for example using `-D` are written back to the cache, but this time
without the qoutes. This results in Kconfig errors on sub-sequent CMake
runs.
Instead of writing the Kconfig value setting back to the CMake cache,
introduce an internal shadow symbol in the cache prefixed with `CLI_`.
This allows the CMake cache to keep the value correctly formatted for
Kconfig extra config creation, while at the same time keep existing
behavior for CONFIG_ symbols read from Kconfig.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2022-08-19 08:58:02 +02:00
|
|
|
set(CLI_${name} "${${name}}")
|
|
|
|
list(APPEND cli_config_list ${name})
|
cmake: kconfig: Keep symbol names sorted in EXTRA_KCONFIG_OPTIONS
This makes checksum calculation over Kconfig fragments more consistent,
which prevents writing a new `.config` when nothing really changes.
To explain this, consider the following sequence:
1. west build . -DCONFIG_XXXX=y -DCONFIG_YYYY=y
2. west build . -DCONFIG_YYYY=y
3. west build . -DCONFIG_XXXX=y
At (1), we set new values for XXXX and YYYY, so the `.config` changes.
At (2), we set a value for YYYY, but it's the same value as before, so
the `.config` doesn't get overwritten.
At (3), we set a value for XXXX, but it's the same value as before, so
the `.config` shouldn't get overwritten... but it does. What happened?
The reason is that the generated `extra_kconfig_options.conf` fragment,
which is included in the checksum calculation, was being populated using
two sets of CMake cache variables:
- past assignments, prefixed with `CLI_${KCONFIG_NAMESPACE}_`.
- new assignments, prefixed with just `${KCONFIG_NAMESPACE}_`.
Usually, past assignments would appear before new assignments, because
the default `${KCONFIG_NAMESPACE}` is CONFIG, which goes after CLI in
alphabetical order. As a result, the contents of EXTRA_KCONFIG_OPTIONS
at (1) and (2):
CONFIG_XXXX=y
CONFIG_YYYY=y
were not identical to its contents at (3):
CONFIG_YYYY=y
CONFIG_XXXX=y
resulting in a different checksum.
This is resolved by stripping out the CLI prefix first, then effectively
"mergesorting" the past and new assignments, before starting to populate
EXTRA_KCONFIG_OPTIONS.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
2023-07-03 02:05:06 +02:00
|
|
|
elseif(DEFINED CLI_${name})
|
|
|
|
# An additional 'CLI_' prefix means that the value was set by the user in
|
|
|
|
# an earlier invocation. Append it to extra config only if no new value was
|
|
|
|
# assigned above.
|
|
|
|
set(EXTRA_KCONFIG_OPTIONS
|
|
|
|
"${EXTRA_KCONFIG_OPTIONS}\n${name}=${CLI_${name}}"
|
|
|
|
)
|
2018-06-18 16:51:43 +02:00
|
|
|
endif()
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
if(EXTRA_KCONFIG_OPTIONS)
|
|
|
|
set(EXTRA_KCONFIG_OPTIONS_FILE ${PROJECT_BINARY_DIR}/misc/generated/extra_kconfig_options.conf)
|
|
|
|
file(WRITE
|
|
|
|
${EXTRA_KCONFIG_OPTIONS_FILE}
|
|
|
|
${EXTRA_KCONFIG_OPTIONS}
|
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
2017-10-27 15:43:34 +02:00
|
|
|
# Bring in extra configuration files dropped in by the user or anyone else;
|
|
|
|
# make sure they are set at the end so we can override any other setting
|
|
|
|
file(GLOB config_files ${APPLICATION_BINARY_DIR}/*.conf)
|
|
|
|
list(SORT config_files)
|
|
|
|
set(
|
|
|
|
merge_config_files
|
|
|
|
${BOARD_DEFCONFIG}
|
2023-01-11 15:58:16 +01:00
|
|
|
${BOARD_REVISION_CONFIG}
|
2023-04-28 18:26:23 +02:00
|
|
|
${board_extension_conf_files}
|
2017-10-27 15:43:34 +02:00
|
|
|
${CONF_FILE_AS_LIST}
|
2019-05-17 19:08:00 +02:00
|
|
|
${shield_conf_files}
|
2023-05-17 12:46:24 +02:00
|
|
|
${EXTRA_CONF_FILE_AS_LIST}
|
2018-06-18 16:51:43 +02:00
|
|
|
${EXTRA_KCONFIG_OPTIONS_FILE}
|
2017-10-27 15:43:34 +02:00
|
|
|
${config_files}
|
|
|
|
)
|
|
|
|
|
|
|
|
# Create a list of absolute paths to the .config sources from
|
|
|
|
# merge_config_files, which is a mix of absolute and relative paths.
|
|
|
|
set(merge_config_files_with_absolute_paths "")
|
|
|
|
foreach(f ${merge_config_files})
|
|
|
|
if(IS_ABSOLUTE ${f})
|
|
|
|
set(path ${f})
|
|
|
|
else()
|
2021-09-01 11:26:53 +02:00
|
|
|
set(path ${APPLICATION_CONFIG_DIR}/${f})
|
2017-10-27 15:43:34 +02:00
|
|
|
endif()
|
|
|
|
|
|
|
|
list(APPEND merge_config_files_with_absolute_paths ${path})
|
|
|
|
endforeach()
|
2021-10-01 15:59:38 +02:00
|
|
|
set(merge_config_files ${merge_config_files_with_absolute_paths})
|
2017-10-27 15:43:34 +02:00
|
|
|
|
2021-10-01 15:59:38 +02:00
|
|
|
foreach(f ${merge_config_files})
|
2017-10-27 15:43:34 +02:00
|
|
|
if(NOT EXISTS ${f} OR IS_DIRECTORY ${f})
|
|
|
|
message(FATAL_ERROR "File not found: ${f}")
|
|
|
|
endif()
|
|
|
|
endforeach()
|
|
|
|
|
2018-01-16 12:35:00 +01:00
|
|
|
# Calculate a checksum of merge_config_files to determine if we need
|
|
|
|
# to re-generate .config
|
|
|
|
set(merge_config_files_checksum "")
|
2021-10-01 15:59:38 +02:00
|
|
|
foreach(f ${merge_config_files})
|
2018-01-16 12:35:00 +01:00
|
|
|
file(MD5 ${f} checksum)
|
|
|
|
set(merge_config_files_checksum "${merge_config_files_checksum}${checksum}")
|
2017-10-27 15:43:34 +02:00
|
|
|
endforeach()
|
|
|
|
|
2018-01-16 12:35:00 +01:00
|
|
|
# Create a new .config if it does not exists, or if the checksum of
|
|
|
|
# the dependencies has changed
|
|
|
|
set(merge_config_files_checksum_file ${PROJECT_BINARY_DIR}/.cmake.dotconfig.checksum)
|
2018-08-02 11:58:07 +02:00
|
|
|
set(CREATE_NEW_DOTCONFIG 1)
|
|
|
|
# Check if the checksum file exists too before trying to open it, though it
|
|
|
|
# should under normal circumstances
|
2018-08-03 13:58:30 +02:00
|
|
|
if(EXISTS ${DOTCONFIG} AND EXISTS ${merge_config_files_checksum_file})
|
2018-01-16 12:35:00 +01:00
|
|
|
# Read out what the checksum was previously
|
|
|
|
file(READ
|
|
|
|
${merge_config_files_checksum_file}
|
|
|
|
merge_config_files_checksum_prev
|
|
|
|
)
|
|
|
|
if(
|
|
|
|
${merge_config_files_checksum} STREQUAL
|
|
|
|
${merge_config_files_checksum_prev}
|
|
|
|
)
|
2018-08-02 11:58:07 +02:00
|
|
|
# Checksum is the same as before
|
2018-01-16 12:35:00 +01:00
|
|
|
set(CREATE_NEW_DOTCONFIG 0)
|
|
|
|
endif()
|
|
|
|
endif()
|
2018-01-16 12:39:20 +01:00
|
|
|
|
2018-01-16 12:35:00 +01:00
|
|
|
if(CREATE_NEW_DOTCONFIG)
|
2023-03-16 14:49:59 +01:00
|
|
|
set(input_configs_flags --handwritten-input-configs)
|
|
|
|
set(input_configs ${merge_config_files} ${FORCED_CONF_FILE})
|
2018-01-16 12:39:20 +01:00
|
|
|
else()
|
2023-03-16 14:49:59 +01:00
|
|
|
set(input_configs ${DOTCONFIG} ${FORCED_CONF_FILE})
|
|
|
|
endif()
|
|
|
|
|
|
|
|
if(DEFINED FORCED_CONF_FILE)
|
|
|
|
list(APPEND input_configs_flags --forced-input-configs)
|
2018-01-16 12:39:20 +01:00
|
|
|
endif()
|
|
|
|
|
2021-12-16 17:13:54 +01:00
|
|
|
cmake_path(GET AUTOCONF_H PARENT_PATH autoconf_h_path)
|
|
|
|
if(NOT EXISTS ${autoconf_h_path})
|
|
|
|
file(MAKE_DIRECTORY ${autoconf_h_path})
|
|
|
|
endif()
|
|
|
|
|
2018-01-16 12:39:20 +01:00
|
|
|
execute_process(
|
2020-08-25 11:02:45 +02:00
|
|
|
COMMAND ${CMAKE_COMMAND} -E env
|
|
|
|
${COMMON_KCONFIG_ENV_SETTINGS}
|
2021-12-02 07:33:19 +01:00
|
|
|
SHIELD_AS_LIST=${SHIELD_AS_LIST_ESCAPED_COMMAND}
|
2018-01-16 12:39:20 +01:00
|
|
|
${PYTHON_EXECUTABLE}
|
2018-04-24 12:47:21 +02:00
|
|
|
${ZEPHYR_BASE}/scripts/kconfig/kconfig.py
|
2020-02-12 15:42:09 +01:00
|
|
|
--zephyr-base=${ZEPHYR_BASE}
|
2023-03-16 14:49:59 +01:00
|
|
|
${input_configs_flags}
|
2018-01-16 12:39:20 +01:00
|
|
|
${KCONFIG_ROOT}
|
2018-09-28 10:15:17 +02:00
|
|
|
${DOTCONFIG}
|
|
|
|
${AUTOCONF_H}
|
2019-02-20 17:49:46 +01:00
|
|
|
${PARSED_KCONFIG_SOURCES_TXT}
|
kconfig/cmake: Improve reconfiguration behavior
There are some issues with the behavior when rerunning CMake in an
already initialized build directory:
1. The check for assignments to promptless symbols in configuration
fragments isn't run when reconfiguring, because it only runs if
zephyr/.config doesn't exist
2. As outlined in
https://github.com/zephyrproject-rtos/zephyr/issues/9573, you can
get into situations where zephyr/.config is invalid (e.g. due to
being outdated), but menuconfig/guiconfig can't be run to fix it
3. If kconfig.py fails while merging fragments during reconfiguration,
it will ignore the fragments during the next reconfiguration and use
the existing zephyr/.config instead, because the fragment checksum
is calculated and saved before running kconfig.py
(Footnote: The input configuration file(s) to kconfig.py can be either a
list of configuration fragments, when merging fragments, or just
zephyr/.config, if the merged configuration is up-to-date. The output
configuration file is always zephyr/.config.)
To fix the first two issues, explicitly tell kconfig.py when it's
dealing with handwritten configuration input (fragments), via a new
--handwritten-input-configs flag. This is more robust than checking
whether zephyr/.config exists, which was the old logic.
When dealing with handwritten input, there should be no assignments to
promptless symbols. Assignments to promptless symbols is expected in
zephyr/.config however, because it doubles as configuration output.
When running menuconfig/guiconfig, the input configuration is
zephyr/.config rather than configuration fragments, so this change also
makes sure that menuconfig can always be run as long as zephyr/.config
exists and is up-to-date.
To fix the last issue, only write the checksum for the configuration
fragments if kconfig.py succeeds (which means it wrote a
zephyr/.config).
Also improve naming a bit, add help texts for the command-line
parameters to kconfig.py, and simplify write_kconfig_filenames() by
moving logic into it.
Partial fix for
https://github.com/zephyrproject-rtos/zephyr/issues/9573, without the
part in #issuecomment-469701831. Can still run into issues when e.g.
when CMake files can't make sense of settings.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-01-20 11:25:13 +01:00
|
|
|
${input_configs}
|
2018-01-16 12:39:20 +01:00
|
|
|
WORKING_DIRECTORY ${APPLICATION_SOURCE_DIR}
|
|
|
|
# The working directory is set to the app dir such that the user
|
|
|
|
# can use relative paths in CONF_FILE, e.g. CONF_FILE=nrf5.conf
|
|
|
|
RESULT_VARIABLE ret
|
2018-01-08 12:42:39 +01:00
|
|
|
)
|
2018-01-16 12:39:20 +01:00
|
|
|
if(NOT "${ret}" STREQUAL "0")
|
|
|
|
message(FATAL_ERROR "command failed with return code: ${ret}")
|
|
|
|
endif()
|
2018-01-16 12:35:00 +01:00
|
|
|
|
kconfig/cmake: Improve reconfiguration behavior
There are some issues with the behavior when rerunning CMake in an
already initialized build directory:
1. The check for assignments to promptless symbols in configuration
fragments isn't run when reconfiguring, because it only runs if
zephyr/.config doesn't exist
2. As outlined in
https://github.com/zephyrproject-rtos/zephyr/issues/9573, you can
get into situations where zephyr/.config is invalid (e.g. due to
being outdated), but menuconfig/guiconfig can't be run to fix it
3. If kconfig.py fails while merging fragments during reconfiguration,
it will ignore the fragments during the next reconfiguration and use
the existing zephyr/.config instead, because the fragment checksum
is calculated and saved before running kconfig.py
(Footnote: The input configuration file(s) to kconfig.py can be either a
list of configuration fragments, when merging fragments, or just
zephyr/.config, if the merged configuration is up-to-date. The output
configuration file is always zephyr/.config.)
To fix the first two issues, explicitly tell kconfig.py when it's
dealing with handwritten configuration input (fragments), via a new
--handwritten-input-configs flag. This is more robust than checking
whether zephyr/.config exists, which was the old logic.
When dealing with handwritten input, there should be no assignments to
promptless symbols. Assignments to promptless symbols is expected in
zephyr/.config however, because it doubles as configuration output.
When running menuconfig/guiconfig, the input configuration is
zephyr/.config rather than configuration fragments, so this change also
makes sure that menuconfig can always be run as long as zephyr/.config
exists and is up-to-date.
To fix the last issue, only write the checksum for the configuration
fragments if kconfig.py succeeds (which means it wrote a
zephyr/.config).
Also improve naming a bit, add help texts for the command-line
parameters to kconfig.py, and simplify write_kconfig_filenames() by
moving logic into it.
Partial fix for
https://github.com/zephyrproject-rtos/zephyr/issues/9573, without the
part in #issuecomment-469701831. Can still run into issues when e.g.
when CMake files can't make sense of settings.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2020-01-20 11:25:13 +01:00
|
|
|
if(CREATE_NEW_DOTCONFIG)
|
|
|
|
# Write the new configuration fragment checksum. Only do this if kconfig.py
|
|
|
|
# succeeds, to avoid marking zephyr/.config as up-to-date when it hasn't been
|
|
|
|
# regenerated.
|
|
|
|
file(WRITE ${merge_config_files_checksum_file}
|
|
|
|
${merge_config_files_checksum})
|
|
|
|
endif()
|
|
|
|
|
2019-02-20 17:49:46 +01:00
|
|
|
# Read out the list of 'Kconfig' sources that were used by the engine.
|
|
|
|
file(STRINGS ${PARSED_KCONFIG_SOURCES_TXT} PARSED_KCONFIG_SOURCES_LIST)
|
|
|
|
|
|
|
|
# Force CMAKE configure when the Kconfig sources or configuration files changes.
|
2019-02-20 17:42:09 +01:00
|
|
|
foreach(kconfig_input
|
|
|
|
${merge_config_files}
|
|
|
|
${DOTCONFIG}
|
2019-02-20 17:49:46 +01:00
|
|
|
${PARSED_KCONFIG_SOURCES_LIST}
|
2019-02-20 17:42:09 +01:00
|
|
|
)
|
|
|
|
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${kconfig_input})
|
2018-01-16 12:35:00 +01:00
|
|
|
endforeach()
|
|
|
|
|
2020-12-07 17:57:30 +01:00
|
|
|
add_custom_target(config-twister DEPENDS ${DOTCONFIG})
|
2017-10-27 15:43:34 +02:00
|
|
|
|
2018-12-12 10:25:32 +01:00
|
|
|
# Remove the CLI Kconfig symbols from the namespace and
|
|
|
|
# CMakeCache.txt. If the symbols end up in DOTCONFIG they will be
|
|
|
|
# re-introduced to the namespace through 'import_kconfig'.
|
cmake: kconfig: preserved quotes for Kconfig string values
Fixes: #48950
Kconfig requires quoted strings in its configuration files, like this:
> CONFIG_A_STRING="foo bar"
But CMake requires expects that strings are without additional qoutes,
and therefore qoutes are stripped when loading Kconfig config filers
into CMake.
This is particular important when the string in Kconfig is a path to a
file. In this case, not stripping the quotes leads to an error as the
file cannot be found.
When users pass a string to Kconfig through CMake, they are expected to
pass it so that qoutes are correct seen from Kconfig, that is:
> cmake -DCONFIG_A_STRING=\"foo bar\"
In CMake, those qoutes are written as-is to Kconfig extra config file,
and then removed in the CMake cache.
After Kconfig processing, the Kconfig settings are read back to CMake
but without quotes. Settings that was passed through the CMake cache,
for example using `-D` are written back to the cache, but this time
without the qoutes. This results in Kconfig errors on sub-sequent CMake
runs.
Instead of writing the Kconfig value setting back to the CMake cache,
introduce an internal shadow symbol in the cache prefixed with `CLI_`.
This allows the CMake cache to keep the value correctly formatted for
Kconfig extra config creation, while at the same time keep existing
behavior for CONFIG_ symbols read from Kconfig.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2022-08-19 08:58:02 +02:00
|
|
|
foreach (name ${cli_config_list})
|
|
|
|
unset(${name})
|
|
|
|
unset(${name} CACHE)
|
2018-12-12 10:25:32 +01:00
|
|
|
endforeach()
|
|
|
|
|
cmake: kconfig: Preserve correct CLI assignments across re-runs
This tiny patch makes two improvements:
1. Preserve boolean (=n) assignments from command-line.
This fixes an issue where, if a symbol with `default y` were turned off
via command-line, e.g., `-DCONFIG_BOOT_BANNER=n`, a CMake re-run would
revert that symbol back to its default value.
To avoid this, the assignment should have been preserved in CMake cache
as `CLI_CONFIG_BOOT_BANNER:INTERNAL=n`. However, `kconfig.cmake` clears
unset variables from cache, and (=n) symbols become unset variables, so
an exception had to be made for them.
2. Discard invalid assignments from command-line.
Although `kconfig.cmake` takes care to discard assignments to symbols
which get unset by Kconfig, it wasn't handling the case where Kconfig
would keep the symbol but replace its value, making the CMake-cached
assignment invalid.
For example, this assignment:
west build . -DCONFIG_PRINTK=n
could be invalidated if PRINTK were selected by, e.g., BOOT_BANNER,
producing this warning:
PRINTK (...) was assigned the value 'n' but got the value 'y'. (...)
Still, the old value of (=n) was being cached. One way in which this was
evident was when setting an unrelated symbol in a separate invocation:
west build . -DCONFIG_MAIN_STACK_SIZE=512
the same warning for PRINTK would show up again.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
2023-07-31 10:48:04 +02:00
|
|
|
# Before importing the symbol values from DOTCONFIG, process the CLI values by
|
|
|
|
# re-importing them from EXTRA_KCONFIG_OPTIONS_FILE. Later, we want to compare
|
|
|
|
# the values from both files, and 'import_kconfig' will make this easier.
|
|
|
|
if(EXTRA_KCONFIG_OPTIONS_FILE)
|
|
|
|
import_kconfig(${KCONFIG_NAMESPACE} ${EXTRA_KCONFIG_OPTIONS_FILE})
|
|
|
|
foreach (name ${cache_variable_names})
|
|
|
|
if(DEFINED ${name})
|
|
|
|
set(temp_${name} "${${name}}")
|
|
|
|
unset(${name})
|
|
|
|
endif()
|
|
|
|
endforeach()
|
|
|
|
endif()
|
|
|
|
|
2021-11-27 11:50:37 +01:00
|
|
|
# Import the .config file and make all settings available in CMake processing.
|
|
|
|
import_kconfig(${KCONFIG_NAMESPACE} ${DOTCONFIG})
|
2018-12-12 10:25:32 +01:00
|
|
|
|
cmake: kconfig: preserved quotes for Kconfig string values
Fixes: #48950
Kconfig requires quoted strings in its configuration files, like this:
> CONFIG_A_STRING="foo bar"
But CMake requires expects that strings are without additional qoutes,
and therefore qoutes are stripped when loading Kconfig config filers
into CMake.
This is particular important when the string in Kconfig is a path to a
file. In this case, not stripping the quotes leads to an error as the
file cannot be found.
When users pass a string to Kconfig through CMake, they are expected to
pass it so that qoutes are correct seen from Kconfig, that is:
> cmake -DCONFIG_A_STRING=\"foo bar\"
In CMake, those qoutes are written as-is to Kconfig extra config file,
and then removed in the CMake cache.
After Kconfig processing, the Kconfig settings are read back to CMake
but without quotes. Settings that was passed through the CMake cache,
for example using `-D` are written back to the cache, but this time
without the qoutes. This results in Kconfig errors on sub-sequent CMake
runs.
Instead of writing the Kconfig value setting back to the CMake cache,
introduce an internal shadow symbol in the cache prefixed with `CLI_`.
This allows the CMake cache to keep the value correctly formatted for
Kconfig extra config creation, while at the same time keep existing
behavior for CONFIG_ symbols read from Kconfig.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2022-08-19 08:58:02 +02:00
|
|
|
# Cache the CLI Kconfig symbols that survived through Kconfig, prefixed with CLI_.
|
|
|
|
# Remove those who might have changed compared to earlier runs, if they no longer appears.
|
cmake: kconfig: Preserve correct CLI assignments across re-runs
This tiny patch makes two improvements:
1. Preserve boolean (=n) assignments from command-line.
This fixes an issue where, if a symbol with `default y` were turned off
via command-line, e.g., `-DCONFIG_BOOT_BANNER=n`, a CMake re-run would
revert that symbol back to its default value.
To avoid this, the assignment should have been preserved in CMake cache
as `CLI_CONFIG_BOOT_BANNER:INTERNAL=n`. However, `kconfig.cmake` clears
unset variables from cache, and (=n) symbols become unset variables, so
an exception had to be made for them.
2. Discard invalid assignments from command-line.
Although `kconfig.cmake` takes care to discard assignments to symbols
which get unset by Kconfig, it wasn't handling the case where Kconfig
would keep the symbol but replace its value, making the CMake-cached
assignment invalid.
For example, this assignment:
west build . -DCONFIG_PRINTK=n
could be invalidated if PRINTK were selected by, e.g., BOOT_BANNER,
producing this warning:
PRINTK (...) was assigned the value 'n' but got the value 'y'. (...)
Still, the old value of (=n) was being cached. One way in which this was
evident was when setting an unrelated symbol in a separate invocation:
west build . -DCONFIG_MAIN_STACK_SIZE=512
the same warning for PRINTK would show up again.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
2023-07-31 10:48:04 +02:00
|
|
|
foreach (name ${cache_variable_names})
|
|
|
|
# Note: "${CLI_${name}}" is the verbatim value of ${name} from command-line,
|
|
|
|
# while "${temp_${name}}" is the same value processed by 'import_kconfig'.
|
|
|
|
if(((NOT DEFINED ${name}) AND (NOT DEFINED temp_${name})) OR
|
|
|
|
((DEFINED ${name}) AND (DEFINED temp_${name}) AND (${name} STREQUAL temp_${name})))
|
cmake: kconfig: preserved quotes for Kconfig string values
Fixes: #48950
Kconfig requires quoted strings in its configuration files, like this:
> CONFIG_A_STRING="foo bar"
But CMake requires expects that strings are without additional qoutes,
and therefore qoutes are stripped when loading Kconfig config filers
into CMake.
This is particular important when the string in Kconfig is a path to a
file. In this case, not stripping the quotes leads to an error as the
file cannot be found.
When users pass a string to Kconfig through CMake, they are expected to
pass it so that qoutes are correct seen from Kconfig, that is:
> cmake -DCONFIG_A_STRING=\"foo bar\"
In CMake, those qoutes are written as-is to Kconfig extra config file,
and then removed in the CMake cache.
After Kconfig processing, the Kconfig settings are read back to CMake
but without quotes. Settings that was passed through the CMake cache,
for example using `-D` are written back to the cache, but this time
without the qoutes. This results in Kconfig errors on sub-sequent CMake
runs.
Instead of writing the Kconfig value setting back to the CMake cache,
introduce an internal shadow symbol in the cache prefixed with `CLI_`.
This allows the CMake cache to keep the value correctly formatted for
Kconfig extra config creation, while at the same time keep existing
behavior for CONFIG_ symbols read from Kconfig.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2022-08-19 08:58:02 +02:00
|
|
|
set(CLI_${name} ${CLI_${name}} CACHE INTERNAL "")
|
|
|
|
else()
|
|
|
|
unset(CLI_${name} CACHE)
|
2018-12-12 10:25:32 +01:00
|
|
|
endif()
|
cmake: kconfig: Preserve correct CLI assignments across re-runs
This tiny patch makes two improvements:
1. Preserve boolean (=n) assignments from command-line.
This fixes an issue where, if a symbol with `default y` were turned off
via command-line, e.g., `-DCONFIG_BOOT_BANNER=n`, a CMake re-run would
revert that symbol back to its default value.
To avoid this, the assignment should have been preserved in CMake cache
as `CLI_CONFIG_BOOT_BANNER:INTERNAL=n`. However, `kconfig.cmake` clears
unset variables from cache, and (=n) symbols become unset variables, so
an exception had to be made for them.
2. Discard invalid assignments from command-line.
Although `kconfig.cmake` takes care to discard assignments to symbols
which get unset by Kconfig, it wasn't handling the case where Kconfig
would keep the symbol but replace its value, making the CMake-cached
assignment invalid.
For example, this assignment:
west build . -DCONFIG_PRINTK=n
could be invalidated if PRINTK were selected by, e.g., BOOT_BANNER,
producing this warning:
PRINTK (...) was assigned the value 'n' but got the value 'y'. (...)
Still, the old value of (=n) was being cached. One way in which this was
evident was when setting an unrelated symbol in a separate invocation:
west build . -DCONFIG_MAIN_STACK_SIZE=512
the same warning for PRINTK would show up again.
Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
2023-07-31 10:48:04 +02:00
|
|
|
unset(temp_${name})
|
2018-12-12 10:25:32 +01:00
|
|
|
endforeach()
|