alex/esp-idf
alex/esp-idf
1
0
Fork 0
mirror of https://github.com/espressif/esp-idf.git synced 2024-10-05 20:47:46 -04:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
a2e56227cc
esp-idf/tools/cmake/targets.cmake

173 lines
6.4 KiB
CMake
Raw Normal View History

tools: move target guessing into cmake The _guess_or_check_idf_target() function has sdkconfig and sdkconfig.defaults file names hardcoded. Since config file names may be specified with SDKCONFIG or SDKCONFIG_DEFAULTS cmake vars, directly in CMakeLists.txt or passed in with the -D cmake option, they are not respected. Problem is when SDKCONFIG or SDKCONFIG_DEFAULTS is set in CMakeLists.txt. While idf can detect cmake vars passed through it to cmake via the -D option, detecting SDKCONFIG and SDKCONFIG_DEFAULTS vars settings in CMakeLists.txt would require to parse it. This seems like error prone approach. Also if the vars defined by the -D option are passed directly to cmake, not via idf, they will not be visible to idf. It seems reasonable to move the logic into cmake, where we know the correct SDKCONFIG and SDKCONFIG_DEFAULTS values. So the IDF_TARGET detection/guessing is moved into targets.cmake, where the IDF_TARGET is actually set. The target is guessed based on the following precendence. 1) $ENV{IDF_TARGET} 2) IDF_TARGET 3) SDKCONFIG 4) sdkconfig 5) SDKCONFIG_DEFAULTS if non-empty or $ENV{SDKCONFIG_DEFAULTS} if non-empty or sdkconfig.defaults 6) esp32 All config files referred in $ENV{SDKCONFIG_DEFAULTS} and SDKCONFIG_DEFAULTS are searched, compared to the current behaviour. First target found in the above chain is used. The original _guess_or_check_idf_target() is renamed to _check_idf_target() and used for the target consistency checks only. The get_sdkconfig_filename() helper is now used to get the sdkconfig file for consistency checks. It looks in SDKCONFIG specified with the -D option and project_description.json. With this change config full paths are reported in messages, so it's clear e.g. from which config the target was guessed from or which config has consistency problem. test_non_default_target.py was adjusted to this change and also new test for testing the IDF_TARGET guessing was added. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-02-23 04:56:06 -05:00
#
# Get target from single sdkconfig file
#
function(__target_from_config config target_out file_out)
set(${target_out} NOTFOUND PARENT_SCOPE)
set(${file_out} NOTFOUND PARENT_SCOPE)
if(NOT EXISTS "${config}")
return()
endif()
file(STRINGS "${config}" lines)
foreach(line ${lines})
if(NOT "${line}" MATCHES "^CONFIG_IDF_TARGET=\"[^\"]+\"$")
continue()
endif()
string(REGEX REPLACE "CONFIG_IDF_TARGET=\"([^\"]+)\"" "\\1" target "${line}")
set(${target_out} ${target} PARENT_SCOPE)
set(${file_out} ${config} PARENT_SCOPE)
return()
endforeach()
endfunction()
#
# Get target from list of sdkconfig files
#
function(__target_from_configs configs target_out file_out)
set(target NOTFOUND)
set(file NOTFOUND)
foreach(config ${configs})
message(DEBUG "Searching for target in '${config}'")
get_filename_component(config "${config}" ABSOLUTE)
__target_from_config("${config}" target file)
if(target)
break()
endif()
endforeach()
set(${target_out} ${target} PARENT_SCOPE)
set(${file_out} ${file} PARENT_SCOPE)
endfunction()
#
# Search for target in config files in the following order.
# SDKCONFIG cmake var, default sdkconfig, SDKCONFIG_DEFAULTS cmake var
# if non-empty or SDKCONFIG_DEFAULTS env var if non-empty or
# sdkconfig.defaults.
#
function(__target_guess target_out file_out)
# Select sdkconfig_defaults to look for target
if(SDKCONFIG_DEFAULTS)
set(defaults "${SDKCONFIG_DEFAULTS}")
elseif(DEFINED ENV{SDKCONFIG_DEFAULTS})
set(defaults "$ENV{SDKCONFIG_DEFAULTS}")
endif()
if(NOT defaults)
set(defaults "${CMAKE_SOURCE_DIR}/sdkconfig.defaults")
endif()
set(configs "${SDKCONFIG}" "${CMAKE_SOURCE_DIR}/sdkconfig" "${defaults}")
message(DEBUG "Searching for target in '${configs}'")
__target_from_configs("${configs}" target file)
set(${target_out} ${target} PARENT_SCOPE)
set(${file_out} ${file} PARENT_SCOPE)
endfunction()
cmake: build system changes
2019-04-26 01:42:10 -04:00
#
# Set the target used for the standard project build.
#
tools: fix custom sdkconfig renaming in set-target Currently the set-target has sdkconfig file name hardcoded to the default one and doesn't honor custom config paths or names. IMHO the only place where we can really now the config file name is in cmake. But also the config should be really renamed only if the set-target action is running. This moves the config file renaming into cmake and it's performed only when _IDF_PY_SET_TARGET_ACTION env. var. is set to 'ON'. This should hopefully guarantee that it's really renamed only while set-target is running. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-03-06 07:52:29 -05:00
macro(__target_init config_file)
build system: support for multiple targets
2018-10-18 23:51:51 -04:00
# Input is IDF_TARGET environement variable
set(env_idf_target $ENV{IDF_TARGET})
if(NOT env_idf_target)
# IDF_TARGET not set in environment, see if it is set in cache
if(IDF_TARGET)
set(env_idf_target ${IDF_TARGET})
else()
tools: move target guessing into cmake The _guess_or_check_idf_target() function has sdkconfig and sdkconfig.defaults file names hardcoded. Since config file names may be specified with SDKCONFIG or SDKCONFIG_DEFAULTS cmake vars, directly in CMakeLists.txt or passed in with the -D cmake option, they are not respected. Problem is when SDKCONFIG or SDKCONFIG_DEFAULTS is set in CMakeLists.txt. While idf can detect cmake vars passed through it to cmake via the -D option, detecting SDKCONFIG and SDKCONFIG_DEFAULTS vars settings in CMakeLists.txt would require to parse it. This seems like error prone approach. Also if the vars defined by the -D option are passed directly to cmake, not via idf, they will not be visible to idf. It seems reasonable to move the logic into cmake, where we know the correct SDKCONFIG and SDKCONFIG_DEFAULTS values. So the IDF_TARGET detection/guessing is moved into targets.cmake, where the IDF_TARGET is actually set. The target is guessed based on the following precendence. 1) $ENV{IDF_TARGET} 2) IDF_TARGET 3) SDKCONFIG 4) sdkconfig 5) SDKCONFIG_DEFAULTS if non-empty or $ENV{SDKCONFIG_DEFAULTS} if non-empty or sdkconfig.defaults 6) esp32 All config files referred in $ENV{SDKCONFIG_DEFAULTS} and SDKCONFIG_DEFAULTS are searched, compared to the current behaviour. First target found in the above chain is used. The original _guess_or_check_idf_target() is renamed to _check_idf_target() and used for the target consistency checks only. The get_sdkconfig_filename() helper is now used to get the sdkconfig file for consistency checks. It looks in SDKCONFIG specified with the -D option and project_description.json. With this change config full paths are reported in messages, so it's clear e.g. from which config the target was guessed from or which config has consistency problem. test_non_default_target.py was adjusted to this change and also new test for testing the IDF_TARGET guessing was added. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-02-23 04:56:06 -05:00
# Try to guess IDF_TARGET from sdkconfig files while honoring
# SDKCONFIG and SDKCONFIG_DEFAULTS values
__target_guess(env_idf_target where)
if(env_idf_target)
message(STATUS "IDF_TARGET is not set, guessed '${env_idf_target}' from sdkconfig '${where}'")
else()
set(env_idf_target esp32)
message(STATUS "IDF_TARGET not set, using default target: ${env_idf_target}")
endif()
build system: support for multiple targets
2018-10-18 23:51:51 -04:00
endif()
tools: add target consistency checks to cmake Extend target checks in cmake, in case it's run directly and not via idf.py or if idf.py misses something. This may happen for example if cmake variables are set in project's CMakeLists.txt. Some clean-ups are included along with the new checks and tests. 1. __target_check() function is removed. IIUC it should never fail, because the selected target is explicitly passed as environmental variable to kconfgen. Meaning the IDF_TARGET from environment variable may not be actually used in kconfgen if IDF_TARGET is already set it cmake cache. Note that the IDF_TARGET environment variable used for kconfgen is not based on the actual IDF_TARGET environment variable set for idf.py, but rather on the value set in __target_init() with set(IDF_TARGET ${env_idf_target} CACHE STRING "IDF Build Target") My understanding is that the original check was introduced to handle situation, where IDF_TARGET was already set in cmake's cache and the IDF_TARGET from environment variable was different. Since the kconfgen would use the original environment variable(not explicitly passed as it is now) the IDF_TARGET in cmake and in sdkconfig could differ. IOW I think the original check was introduced to cope with the following cmake behaviour set(VARIABLE "value1" CACHE STRING "test variable") set(VARIABLE "value2" CACHE STRING "test variable") message("Variable value: ${VARIABLE}") output: Variable value: value1 2. I scratched by head how it is possible that the following code in __target_check() if(NOT ${IDF_TARGET} STREQUAL ${env_idf_target}) could fail if IDF_TARGET is not set. For example in clean project IDF_TARGET=esp32 idf.py reconfigure Here env_idf_target==esp32 and IDF_TARGET is not set, so I would expect that cmake will fail with error message that the cache and env target do not match. The thing is that the variable evaluation is done before the if command, so it actually sees this if(NOT STREQUAL esp32) which is false and the error is not printed. It can be seen with 'cmake --trace-expand' command. I don't know if this was used on purpose or it worked just as a coincidence, but I find it very confusing, so I added explicit check if the IDF_TARGET is defined before the actual check. Same for CMAKE_TOOLCHAIN_FILE. 3. Error messages are not formated(line-wrapped) by cmake's markup so it's easier to check the output in tests. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-02-28 12:15:12 -05:00
endif()
# Check if selected target is consistent with CMake cache
if(DEFINED CACHE{IDF_TARGET})
if(NOT $CACHE{IDF_TARGET} STREQUAL ${env_idf_target})
message(FATAL_ERROR " IDF_TARGET '$CACHE{IDF_TARGET}' in CMake"
" cache does not match currently selected IDF_TARGET '${env_idf_target}'."
" To change the target, clear the build directory and sdkconfig file,"
" and build the project again.")
endif()
endif()
# Check if selected target is consistent with sdkconfig
tools: fix custom sdkconfig renaming in set-target Currently the set-target has sdkconfig file name hardcoded to the default one and doesn't honor custom config paths or names. IMHO the only place where we can really now the config file name is in cmake. But also the config should be really renamed only if the set-target action is running. This moves the config file renaming into cmake and it's performed only when _IDF_PY_SET_TARGET_ACTION env. var. is set to 'ON'. This should hopefully guarantee that it's really renamed only while set-target is running. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-03-06 07:52:29 -05:00
__target_from_config("${config_file}" sdkconfig_target where)
tools: add target consistency checks to cmake Extend target checks in cmake, in case it's run directly and not via idf.py or if idf.py misses something. This may happen for example if cmake variables are set in project's CMakeLists.txt. Some clean-ups are included along with the new checks and tests. 1. __target_check() function is removed. IIUC it should never fail, because the selected target is explicitly passed as environmental variable to kconfgen. Meaning the IDF_TARGET from environment variable may not be actually used in kconfgen if IDF_TARGET is already set it cmake cache. Note that the IDF_TARGET environment variable used for kconfgen is not based on the actual IDF_TARGET environment variable set for idf.py, but rather on the value set in __target_init() with set(IDF_TARGET ${env_idf_target} CACHE STRING "IDF Build Target") My understanding is that the original check was introduced to handle situation, where IDF_TARGET was already set in cmake's cache and the IDF_TARGET from environment variable was different. Since the kconfgen would use the original environment variable(not explicitly passed as it is now) the IDF_TARGET in cmake and in sdkconfig could differ. IOW I think the original check was introduced to cope with the following cmake behaviour set(VARIABLE "value1" CACHE STRING "test variable") set(VARIABLE "value2" CACHE STRING "test variable") message("Variable value: ${VARIABLE}") output: Variable value: value1 2. I scratched by head how it is possible that the following code in __target_check() if(NOT ${IDF_TARGET} STREQUAL ${env_idf_target}) could fail if IDF_TARGET is not set. For example in clean project IDF_TARGET=esp32 idf.py reconfigure Here env_idf_target==esp32 and IDF_TARGET is not set, so I would expect that cmake will fail with error message that the cache and env target do not match. The thing is that the variable evaluation is done before the if command, so it actually sees this if(NOT STREQUAL esp32) which is false and the error is not printed. It can be seen with 'cmake --trace-expand' command. I don't know if this was used on purpose or it worked just as a coincidence, but I find it very confusing, so I added explicit check if the IDF_TARGET is defined before the actual check. Same for CMAKE_TOOLCHAIN_FILE. 3. Error messages are not formated(line-wrapped) by cmake's markup so it's easier to check the output in tests. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-02-28 12:15:12 -05:00
if(sdkconfig_target)
if(NOT ${sdkconfig_target} STREQUAL ${env_idf_target})
message(FATAL_ERROR " Target '${sdkconfig_target}' in sdkconfig '${where}'"
" does not match currently selected IDF_TARGET '${IDF_TARGET}'."
" To change the target, clear the build directory and sdkconfig file,"
" and build the project again.")
build system: support for multiple targets
2018-10-18 23:51:51 -04:00
endif()
endif()
tools: add target consistency checks to cmake Extend target checks in cmake, in case it's run directly and not via idf.py or if idf.py misses something. This may happen for example if cmake variables are set in project's CMakeLists.txt. Some clean-ups are included along with the new checks and tests. 1. __target_check() function is removed. IIUC it should never fail, because the selected target is explicitly passed as environmental variable to kconfgen. Meaning the IDF_TARGET from environment variable may not be actually used in kconfgen if IDF_TARGET is already set it cmake cache. Note that the IDF_TARGET environment variable used for kconfgen is not based on the actual IDF_TARGET environment variable set for idf.py, but rather on the value set in __target_init() with set(IDF_TARGET ${env_idf_target} CACHE STRING "IDF Build Target") My understanding is that the original check was introduced to handle situation, where IDF_TARGET was already set in cmake's cache and the IDF_TARGET from environment variable was different. Since the kconfgen would use the original environment variable(not explicitly passed as it is now) the IDF_TARGET in cmake and in sdkconfig could differ. IOW I think the original check was introduced to cope with the following cmake behaviour set(VARIABLE "value1" CACHE STRING "test variable") set(VARIABLE "value2" CACHE STRING "test variable") message("Variable value: ${VARIABLE}") output: Variable value: value1 2. I scratched by head how it is possible that the following code in __target_check() if(NOT ${IDF_TARGET} STREQUAL ${env_idf_target}) could fail if IDF_TARGET is not set. For example in clean project IDF_TARGET=esp32 idf.py reconfigure Here env_idf_target==esp32 and IDF_TARGET is not set, so I would expect that cmake will fail with error message that the cache and env target do not match. The thing is that the variable evaluation is done before the if command, so it actually sees this if(NOT STREQUAL esp32) which is false and the error is not printed. It can be seen with 'cmake --trace-expand' command. I don't know if this was used on purpose or it worked just as a coincidence, but I find it very confusing, so I added explicit check if the IDF_TARGET is defined before the actual check. Same for CMAKE_TOOLCHAIN_FILE. 3. Error messages are not formated(line-wrapped) by cmake's markup so it's easier to check the output in tests. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-02-28 12:15:12 -05:00
# IDF_TARGET will be used by component manager, make sure it is set
build system: support for multiple targets
2018-10-18 23:51:51 -04:00
set(ENV{IDF_TARGET} ${env_idf_target})
# Finally, set IDF_TARGET in cache
set(IDF_TARGET ${env_idf_target} CACHE STRING "IDF Build Target")
endmacro()
cmake: build system changes
2019-04-26 01:42:10 -04:00
#
# Used by the project CMake file to set the toolchain before project() call.
#
macro(__target_set_toolchain)
idf_build_get_property(idf_path IDF_PATH)
cmake: allow selection of clang based toolchain This is an experimental feature intended at the moment for ESP-IDF developers only. If IDF_TOOLCHAIN=clang environment variable or CMake variable is set, use toolchain-clang-esp32xx.cmake instead of toolchain-esp32xx.cmake. These changes aren't sufficient to actually build any IDF project with clang; subsequent commits add a few workarounds required to do this. Toolchain files are added for esp32 and esp32s2, which are the targets supported in our llvm-project fork at the moment.
2021-09-10 12:47:46 -04:00
# See if Clang toolchain should be used
set(env_idf_toolchain $ENV{IDF_TOOLCHAIN})
if(NOT env_idf_toolchain)
# IDF_TOOLCHAIN not set in environment, see if it is set in cache
if(IDF_TOOLCHAIN)
set(env_idf_toolchain ${IDF_TOOLCHAIN})
else()
set(env_idf_toolchain gcc)
endif()
tools: add target consistency checks to cmake Extend target checks in cmake, in case it's run directly and not via idf.py or if idf.py misses something. This may happen for example if cmake variables are set in project's CMakeLists.txt. Some clean-ups are included along with the new checks and tests. 1. __target_check() function is removed. IIUC it should never fail, because the selected target is explicitly passed as environmental variable to kconfgen. Meaning the IDF_TARGET from environment variable may not be actually used in kconfgen if IDF_TARGET is already set it cmake cache. Note that the IDF_TARGET environment variable used for kconfgen is not based on the actual IDF_TARGET environment variable set for idf.py, but rather on the value set in __target_init() with set(IDF_TARGET ${env_idf_target} CACHE STRING "IDF Build Target") My understanding is that the original check was introduced to handle situation, where IDF_TARGET was already set in cmake's cache and the IDF_TARGET from environment variable was different. Since the kconfgen would use the original environment variable(not explicitly passed as it is now) the IDF_TARGET in cmake and in sdkconfig could differ. IOW I think the original check was introduced to cope with the following cmake behaviour set(VARIABLE "value1" CACHE STRING "test variable") set(VARIABLE "value2" CACHE STRING "test variable") message("Variable value: ${VARIABLE}") output: Variable value: value1 2. I scratched by head how it is possible that the following code in __target_check() if(NOT ${IDF_TARGET} STREQUAL ${env_idf_target}) could fail if IDF_TARGET is not set. For example in clean project IDF_TARGET=esp32 idf.py reconfigure Here env_idf_target==esp32 and IDF_TARGET is not set, so I would expect that cmake will fail with error message that the cache and env target do not match. The thing is that the variable evaluation is done before the if command, so it actually sees this if(NOT STREQUAL esp32) which is false and the error is not printed. It can be seen with 'cmake --trace-expand' command. I don't know if this was used on purpose or it worked just as a coincidence, but I find it very confusing, so I added explicit check if the IDF_TARGET is defined before the actual check. Same for CMAKE_TOOLCHAIN_FILE. 3. Error messages are not formated(line-wrapped) by cmake's markup so it's easier to check the output in tests. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-02-28 12:15:12 -05:00
elseif(DEFINED CACHE{IDF_TOOLCHAIN})
cmake: allow selection of clang based toolchain This is an experimental feature intended at the moment for ESP-IDF developers only. If IDF_TOOLCHAIN=clang environment variable or CMake variable is set, use toolchain-clang-esp32xx.cmake instead of toolchain-esp32xx.cmake. These changes aren't sufficient to actually build any IDF project with clang; subsequent commits add a few workarounds required to do this. Toolchain files are added for esp32 and esp32s2, which are the targets supported in our llvm-project fork at the moment.
2021-09-10 12:47:46 -04:00
# IDF_TOOLCHAIN set both in environment and in cache, must be the same
tools: add target consistency checks to cmake Extend target checks in cmake, in case it's run directly and not via idf.py or if idf.py misses something. This may happen for example if cmake variables are set in project's CMakeLists.txt. Some clean-ups are included along with the new checks and tests. 1. __target_check() function is removed. IIUC it should never fail, because the selected target is explicitly passed as environmental variable to kconfgen. Meaning the IDF_TARGET from environment variable may not be actually used in kconfgen if IDF_TARGET is already set it cmake cache. Note that the IDF_TARGET environment variable used for kconfgen is not based on the actual IDF_TARGET environment variable set for idf.py, but rather on the value set in __target_init() with set(IDF_TARGET ${env_idf_target} CACHE STRING "IDF Build Target") My understanding is that the original check was introduced to handle situation, where IDF_TARGET was already set in cmake's cache and the IDF_TARGET from environment variable was different. Since the kconfgen would use the original environment variable(not explicitly passed as it is now) the IDF_TARGET in cmake and in sdkconfig could differ. IOW I think the original check was introduced to cope with the following cmake behaviour set(VARIABLE "value1" CACHE STRING "test variable") set(VARIABLE "value2" CACHE STRING "test variable") message("Variable value: ${VARIABLE}") output: Variable value: value1 2. I scratched by head how it is possible that the following code in __target_check() if(NOT ${IDF_TARGET} STREQUAL ${env_idf_target}) could fail if IDF_TARGET is not set. For example in clean project IDF_TARGET=esp32 idf.py reconfigure Here env_idf_target==esp32 and IDF_TARGET is not set, so I would expect that cmake will fail with error message that the cache and env target do not match. The thing is that the variable evaluation is done before the if command, so it actually sees this if(NOT STREQUAL esp32) which is false and the error is not printed. It can be seen with 'cmake --trace-expand' command. I don't know if this was used on purpose or it worked just as a coincidence, but I find it very confusing, so I added explicit check if the IDF_TARGET is defined before the actual check. Same for CMAKE_TOOLCHAIN_FILE. 3. Error messages are not formated(line-wrapped) by cmake's markup so it's easier to check the output in tests. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-02-28 12:15:12 -05:00
if(NOT $CACHE{IDF_TOOLCHAIN} STREQUAL ${env_idf_toolchain})
message(FATAL_ERROR " IDF_TOOLCHAIN '$CACHE{IDF_TOOLCHAIN}' in CMake cache does not match"
" currently selected IDF_TOOLCHAIN '${env_idf_toolchain}'. To change the toolchain, clear"
" the build directory and sdkconfig file, and build the project again.")
cmake: allow selection of clang based toolchain This is an experimental feature intended at the moment for ESP-IDF developers only. If IDF_TOOLCHAIN=clang environment variable or CMake variable is set, use toolchain-clang-esp32xx.cmake instead of toolchain-esp32xx.cmake. These changes aren't sufficient to actually build any IDF project with clang; subsequent commits add a few workarounds required to do this. Toolchain files are added for esp32 and esp32s2, which are the targets supported in our llvm-project fork at the moment.
2021-09-10 12:47:46 -04:00
endif()
endif()
# Finally, set IDF_TOOLCHAIN in cache
set(IDF_TOOLCHAIN ${env_idf_toolchain} CACHE STRING "IDF Build Toolchain Type")
if(${env_idf_toolchain} STREQUAL "clang")
set(toolchain_type "clang-")
endif()
tools: add target consistency checks to cmake Extend target checks in cmake, in case it's run directly and not via idf.py or if idf.py misses something. This may happen for example if cmake variables are set in project's CMakeLists.txt. Some clean-ups are included along with the new checks and tests. 1. __target_check() function is removed. IIUC it should never fail, because the selected target is explicitly passed as environmental variable to kconfgen. Meaning the IDF_TARGET from environment variable may not be actually used in kconfgen if IDF_TARGET is already set it cmake cache. Note that the IDF_TARGET environment variable used for kconfgen is not based on the actual IDF_TARGET environment variable set for idf.py, but rather on the value set in __target_init() with set(IDF_TARGET ${env_idf_target} CACHE STRING "IDF Build Target") My understanding is that the original check was introduced to handle situation, where IDF_TARGET was already set in cmake's cache and the IDF_TARGET from environment variable was different. Since the kconfgen would use the original environment variable(not explicitly passed as it is now) the IDF_TARGET in cmake and in sdkconfig could differ. IOW I think the original check was introduced to cope with the following cmake behaviour set(VARIABLE "value1" CACHE STRING "test variable") set(VARIABLE "value2" CACHE STRING "test variable") message("Variable value: ${VARIABLE}") output: Variable value: value1 2. I scratched by head how it is possible that the following code in __target_check() if(NOT ${IDF_TARGET} STREQUAL ${env_idf_target}) could fail if IDF_TARGET is not set. For example in clean project IDF_TARGET=esp32 idf.py reconfigure Here env_idf_target==esp32 and IDF_TARGET is not set, so I would expect that cmake will fail with error message that the cache and env target do not match. The thing is that the variable evaluation is done before the if command, so it actually sees this if(NOT STREQUAL esp32) which is false and the error is not printed. It can be seen with 'cmake --trace-expand' command. I don't know if this was used on purpose or it worked just as a coincidence, but I find it very confusing, so I added explicit check if the IDF_TARGET is defined before the actual check. Same for CMAKE_TOOLCHAIN_FILE. 3. Error messages are not formated(line-wrapped) by cmake's markup so it's easier to check the output in tests. Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
2023-02-28 12:15:12 -05:00
# Check if selected target is consistent with toolchain file in CMake cache
if(DEFINED CMAKE_TOOLCHAIN_FILE)
string(FIND "${CMAKE_TOOLCHAIN_FILE}" "-${toolchain_type}${IDF_TARGET}.cmake" found)
if(${found} EQUAL -1)
get_filename_component(toolchain "${CMAKE_TOOLCHAIN_FILE}" NAME_WE)
message(FATAL_ERROR " CMAKE_TOOLCHAIN_FILE '${toolchain}'"
" does not match currently selected IDF_TARGET '${IDF_TARGET}'."
" To change the target, clear the build directory and sdkconfig file,"
" and build the project again.")
endif()
endif()
cmake: build system changes
2019-04-26 01:42:10 -04:00
# First try to load the toolchain file from the tools/cmake/directory of IDF
cmake: allow selection of clang based toolchain This is an experimental feature intended at the moment for ESP-IDF developers only. If IDF_TOOLCHAIN=clang environment variable or CMake variable is set, use toolchain-clang-esp32xx.cmake instead of toolchain-esp32xx.cmake. These changes aren't sufficient to actually build any IDF project with clang; subsequent commits add a few workarounds required to do this. Toolchain files are added for esp32 and esp32s2, which are the targets supported in our llvm-project fork at the moment.
2021-09-10 12:47:46 -04:00
set(toolchain_file_global ${idf_path}/tools/cmake/toolchain-${toolchain_type}${IDF_TARGET}.cmake)
build system: support for multiple targets
2018-10-18 23:51:51 -04:00
if(EXISTS ${toolchain_file_global})
set(CMAKE_TOOLCHAIN_FILE ${toolchain_file_global})
else()
cmake: don't search for toolchain files in component directory This feature was added when we thought that target components might be added out of IDF tree. That never became possible, and with recent changes in IDF architecture it is unlikely that this feature will be necessary any time soon. Remove it, simplifying the code.
2021-09-10 12:49:45 -04:00
message(FATAL_ERROR "Toolchain file ${toolchain_file_global} not found")
build system: support for multiple targets
2018-10-18 23:51:51 -04:00
endif()
Fix cmake typo
2019-10-04 06:25:51 -04:00
endmacro()
Reference in New Issue Copy Permalink