patrick/zephyr
1
0
Fork 0
Code Issues Pull requests Actions 8 Packages Projects Releases Wiki Activity
zephyr/cmake/app/boilerplate.cmake

631 lines
24 KiB
CMake
Raw Normal View History

license: cleanup: add SPDX Apache-2.0 license identifier Update the files which contain no license information with the 'Apache-2.0' SPDX license identifier. Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of Zephyr, which is Apache version 2. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-04-06 15:08:09 +02:00
# SPDX-License-Identifier: Apache-2.0
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# This file must be included into the toplevel CMakeLists.txt file of
doc: Update documentation to describe use of find_package(Zephyr) This commit changes the current boilerplate include description and instead describes the use of find_package(Zephyr) It also add a section covering additional possibilities when using find_package(Zephyr). - Search order - Zephyr repository application description - Zephyr workspace application description - Zephyr freestanding application description - Environment ZEPHYR_BASE setting - Multiple Zephyr and preference setting Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-03-12 23:34:12 +01:00
# Zephyr applications.
# Zephyr CMake package automatically includes this file when CMake function
# find_package() is used.
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
#
doc: Update documentation to describe use of find_package(Zephyr) This commit changes the current boilerplate include description and instead describes the use of find_package(Zephyr) It also add a section covering additional possibilities when using find_package(Zephyr). - Search order - Zephyr repository application description - Zephyr workspace application description - Zephyr freestanding application description - Environment ZEPHYR_BASE setting - Multiple Zephyr and preference setting Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-03-12 23:34:12 +01:00
# To ensure this file is loaded in a Zephyr application it must start with
# one of those lines:
#
# find_package(Zephyr)
cmake: make find_package(ZephyrUnittest...) REQUIRED This commit is a followup to PR #25808 which updates the tests to ensure the REQUIRED keyword is also used for the ZephyrUnitest package. This provides a better error message when building with CMake and forgetting ZEPHYR_BASE or not registering Zephyr in the CMake package registry. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-05-29 22:17:26 +02:00
# find_package(Zephyr REQUIRED HINTS $ENV{ZEPHYR_BASE})
doc: Update documentation to describe use of find_package(Zephyr) This commit changes the current boilerplate include description and instead describes the use of find_package(Zephyr) It also add a section covering additional possibilities when using find_package(Zephyr). - Search order - Zephyr repository application description - Zephyr workspace application description - Zephyr freestanding application description - Environment ZEPHYR_BASE setting - Multiple Zephyr and preference setting Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-03-12 23:34:12 +01:00
#
cmake: make find_package(ZephyrUnittest...) REQUIRED This commit is a followup to PR #25808 which updates the tests to ensure the REQUIRED keyword is also used for the ZephyrUnitest package. This provides a better error message when building with CMake and forgetting ZEPHYR_BASE or not registering Zephyr in the CMake package registry. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-05-29 22:17:26 +02:00
# The `REQUIRED HINTS $ENV{ZEPHYR_BASE}` variant is required for any application
# inside the Zephyr repository.
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
#
# It exists to reduce boilerplate code that Zephyr expects to be in
# application CMakeLists.txt code.
cmake: increase minimal required version to 3.13.1 Move to latest cmake version with many bug fixes and enhancements. Signed-off-by: Anas Nashif <anas.nashif@intel.com> Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-12-11 16:33:23 +01:00
# CMake version 3.13.1 is the real minimum supported version.
cmake: change policy CMP0000 to NEW Change CMake policy CMP0000 from OLD to NEW to resolve #8355. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-08-03 09:36:52 +02:00
#
# Unfortunately CMake requires the toplevel CMakeLists.txt file to
# define the required version, not even invoking it from an included
# file, like boilerplate.cmake, is sufficient. It is however permitted
# to have multiple invocations of cmake_minimum_required.
#
# Under these restraints we use a second 'cmake_minimum_required'
# invocation in every toplevel CMakeLists.txt.
cmake: increase minimal required version to 3.13.1 Move to latest cmake version with many bug fixes and enhancements. Signed-off-by: Anas Nashif <anas.nashif@intel.com> Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-12-11 16:33:23 +01:00
cmake_minimum_required(VERSION 3.13.1)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: Document CMAKE_SYSTEM_-variables, and add CMAKE_SYSTEM_VERSION Aid user in understanding what CMake expects of: * Document and add CMAKE_SYSTEM_VERSION * Document CMAKE_SYSTEM_NAME * Document CMAKE_SYSTEM_PROCESSOR * Document BUILD_SHARED_LIBS * Document Policies CMP0002, CMP0079 CMAKE_SYSTEM_VERSION is required officially by CMake, but appears unused -- at least now we are compliant. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 16:01:05 +01:00
# CMP0002: "Logical target names must be globally unique"
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake_policy(SET CMP0002 NEW)
cmake: Omit if statement that is always true We had an if-statement around policy 79 because we used to need to support CMake versions before 3.13.0. But now 3.13.1 is the minimum required version so the if statement always evaluates to true and can be omitted. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-27 08:56:35 +01:00
# Use the old CMake behaviour until the build scripts have been ported
# to the new behaviour.
# CMP0079: "target_link_libraries() allows use with targets in other directories"
cmake_policy(SET CMP0079 OLD)
cmake: Fix warning related to policy CMP0079 In CMake 3.13 a warning is produced if one does not explicitly state what the policy for CMP0079 should be. To resolve this warning we set policy CMP0079 to OLD. This is expected to have no semantical change. When we want a semantical change we can flip the policy and port the build scripts to the new behaviour. This fixes #11794 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-12-05 12:19:29 +01:00
cmake: boilerplate: Define properties earlier The properties definitions were not doing much because they were defined after they were used. They were actually overriding the true properties with "". Moving them earlier ensures that the properties behave as expected, as documented global mutable variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-18 13:02:19 +01:00
define_property(GLOBAL PROPERTY ZEPHYR_LIBS
BRIEF_DOCS "Global list of all Zephyr CMake libs that should be linked in"
FULL_DOCS "Global list of all Zephyr CMake libs that should be linked in.
zephyr_library() appends libs to this list.")
set_property(GLOBAL PROPERTY ZEPHYR_LIBS "")
cmake: Introduce Zephyr interface libraries Introduce Zephyr interface libraries to fix #5351. From the documentation: A Zephyr interface library is a thin wrapper over a CMake INTERFACE library. The most important responsibility of this abstraction is to ensure that when a user KConfig-enables a library then the header files of this library will be accessible to the 'app' library. This is done because when a user uses Kconfig to enable a library he expects to be able to include it's header files and call it's functions out-of-the box. A Zephyr interface library should be used when there exists some build information (include directories, defines, compiler flags, etc.) that should be applied to a set of Zephyr libraries and 'app' might be one of these libraries. Zephyr libraries must explicitly call zephyr_library_link_libraries(<interface_library>) to use this build information. 'app' is treated as a special case for usability reasons; a Kconfig option (CONFIG_APP_LINK_WITH_<interface_library>) should exist for each interface_library and will determine if 'app' links with the interface_library. This API has a constructor like the zephyr_library API has, but it Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-27 16:08:06 +01:00
define_property(GLOBAL PROPERTY ZEPHYR_INTERFACE_LIBS
BRIEF_DOCS "Global list of all Zephyr interface libs that should be linked in."
FULL_DOCS "Global list of all Zephyr interface libs that should be linked in.
zephyr_interface_library_named() appends libs to this list.")
set_property(GLOBAL PROPERTY ZEPHYR_INTERFACE_LIBS "")
cmake: boilerplate: Define properties earlier The properties definitions were not doing much because they were defined after they were used. They were actually overriding the true properties with "". Moving them earlier ensures that the properties behave as expected, as documented global mutable variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-18 13:02:19 +01:00
define_property(GLOBAL PROPERTY GENERATED_KERNEL_OBJECT_FILES
BRIEF_DOCS "Object files that are generated after Zephyr has been linked once."
FULL_DOCS "\
Object files that are generated after Zephyr has been linked once.\
May include mmu tables, etc."
)
set_property(GLOBAL PROPERTY GENERATED_KERNEL_OBJECT_FILES "")
define_property(GLOBAL PROPERTY GENERATED_KERNEL_SOURCE_FILES
BRIEF_DOCS "Source files that are generated after Zephyr has been linked once."
FULL_DOCS "\
cmake: Fix minor typo in docs Fix a minor copy-paste error in the help text. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-10-15 11:43:24 +02:00
Source files that are generated after Zephyr has been linked once.\
cmake: boilerplate: Define properties earlier The properties definitions were not doing much because they were defined after they were used. They were actually overriding the true properties with "". Moving them earlier ensures that the properties behave as expected, as documented global mutable variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-18 13:02:19 +01:00
May include isr_tables.c etc."
)
set_property(GLOBAL PROPERTY GENERATED_KERNEL_SOURCE_FILES "")
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(APPLICATION_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR} CACHE PATH "Application Source Directory")
set(APPLICATION_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR} CACHE PATH "Application Binary Directory")
set(__build_dir ${CMAKE_CURRENT_BINARY_DIR}/zephyr)
set(PROJECT_BINARY_DIR ${__build_dir})
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
cmake: manual handling of CMakeCheckCompilerFlag.cmake inclusion Fixes: #30232 This is a workaround for #30232. During Zephyr CMake invocation a plain C compiler is used for DTS. This results in the internal `CheckCompilerFlag.cmake` being included by CMake Later, when the full toolchain is configured, then `CMakeCheckCompilerFlag.cmake` is included. This overloads the `cmake_check_compiler_flag()` function, thus causing #30232. By manualy loading `CMakeCheckCompilerFlag.cmake` then `CheckCompilerFlag.cmake` will overload the functions (and thus win the battle), and because `include_guard(GLOBAL)` is used in `CMakeCheckCompilerFlag.cmake` this file will not be re-included later. It also prints a warning informing the user of the issue. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-11-26 22:02:19 +01:00
if(${CMAKE_VERSION} VERSION_EQUAL 3.19.0 OR
${CMAKE_VERSION} VERSION_EQUAL 3.19.1)
message(WARNING "CMake 3.19.0/3.19.1 contains a bug regarding Toolchain/compiler "
"testing. Consider switching to a different CMake version.\n"
"See more here: \n"
"- https://github.com/zephyrproject-rtos/zephyr/issues/30232\n"
"- https://gitlab.kitware.com/cmake/cmake/-/issues/21497")
# This is a workaround for #30232.
# During Zephyr CMake invocation a plain C compiler is used for DTS.
# This results in the internal `CheckCompilerFlag.cmake` being included by CMake
# Later, when the full toolchain is configured, then `CMakeCheckCompilerFlag.cmake` is included.
# This overloads the `cmake_check_compiler_flag()` function, thus causing #30232.
# By manualy loading `CMakeCheckCompilerFlag.cmake` then `CheckCompilerFlag.cmake` will overload
# the functions (and thus win the battle), and because `include_guard(GLOBAL)` is used in
# `CMakeCheckCompilerFlag.cmake` this file will not be re-included later.
include(${CMAKE_ROOT}/Modules/Internal/CMakeCheckCompilerFlag.cmake)
endif()
build: clean up west build The header printed at the beginning of every west build is kind of annoying. Let's remove it and just print the application source directory at cmake time instead. The build directory and board are already printed there, anyway, and that's all IDE users will see. Let's clean up the BOARD to make it say "board" instead. That matches the west build --board option name a bit more closely and is still legible. Likewise, let's not print any west build messages if we're just incrementally recompiling. That's noisy. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2020-03-05 23:20:18 +01:00
message(STATUS "Application: ${APPLICATION_SOURCE_DIR}")
cmake: Added rule and helper functions for code relocation. This patch creates a rule in the cmake to trigger the generation of linker_relocate.ld and code_relocation.c files. The linker_relocate.ld will create appropriate sections and will link the required functions or variables from all the selected files. The code_relocation.c will have code that is needed for initializing data sections and copy of text sections(if XIP). Also this will contain code that is needed for zeroing of bss. The procedure to invoke this feature is: 1. Enable CONFIG_CODE_RELOCATION in the prj.conf 2. Inside CMakeList.txt in the project we need to mention all the files that needs to get relocated. zephyr_kernel_code_relocate(src/*.c SRAM2) Where the first argument is the file/files and the second argument is the memory where it has be placed. NOTE: The file argument supports glob expressions. NOTE: Step 2 can be done as many times as required. And relative paths can be given here. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-13 11:04:02 +01:00
add_custom_target(code_data_relocation_target)
cmake: rename and move runner_yml_props_target to boilerplate Rename it to "runners_yaml_props_target", because the file name is runners.yaml, not runner.yml. Move it to the boilerplate definition so that we can modify it before cmake/flash/CMakeLists.txt gets run. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2020-08-25 00:00:35 +02:00
# The zephyr/runners.yaml file in the build directory is used to
# configure the scripts/west_commands/runners Python package used
# by 'west flash', 'west debug', etc.
#
# This is a helper target for setting property:value pairs related to
# this file:
#
# Property Description
# -------------- --------------------------------------------------
# bin_file "zephyr.bin" file for flashing
# hex_file "zephyr.hex" file for flashing
# elf_file "zephyr.elf" file for flashing or debugging
# yaml_contents generated contents of runners.yaml
#
# Note: there are quotes around "zephyr.bin" etc. because the actual
# paths can be changed, e.g. to flash signed versions of these files
# for consumption by bootloaders such as MCUboot.
#
# See cmake/flash/CMakeLists.txt for more details.
add_custom_target(runners_yaml_props_target)
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
# CMake's 'project' concept has proven to not be very useful for Zephyr
# due in part to how Zephyr is organized and in part to it not fitting well
# with cross compilation.
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
# Zephyr therefore tries to rely as little as possible on project()
cmake: replace PROJECT_SOURCE_DIR with ZEPHYR_BASE Both variables were used (with the same value) interchangeably throughout CMake files and per the discussion in GH issue, ZEPHYR_BASE is preferred. Also add a comment with explanation of one vs. the other. Tested by building hello_world for several boards ensuring no errors. Fixes #7173. Signed-off-by: Alex Tereschenko <alext.mkrs@gmail.com>
2018-06-14 20:21:18 +02:00
# and its associated variables, e.g. PROJECT_SOURCE_DIR.
# It is recommended to always use ZEPHYR_BASE instead of PROJECT_SOURCE_DIR
# when trying to reference ENV${ZEPHYR_BASE}.
cmake: warn if inconsistency between CMAKE_SOURCE_DIR and ZEPHYR_BASE cmake has a number of issues dealing with symbolic links: https://gitlab.kitware.com/cmake/cmake/issues/16228 One of them can cause cmake to rewrite the -S input from the user and CMAKE_SOURCE_DIR to unexpectedly include symbolic links: https://cmake.org/pipermail/cmake/2019-May/thread.html#69496 Catch this corner case and warn about subtle issues like breaking -fmacro-prefix-map=${ZEPHYR_BASE}= Sample warning message: CMake Warning at ../../CMakeLists.txt:30 (message): ZEPHYR_BASE doesn't match CMAKE_CURRENT_SOURCE_DIR ZEPHYR_BASE = ~/zephyrproject/zephyr PWD = ~/westsymlink/zephyr/samples/hello_world CMAKE_CURRENT_SOURCE_DIR = ~/westsymlink/zephyr You may be using a mix of symbolic links and real paths which causes subtle and hard to debug CMake issues. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-01 00:37:40 +02:00
cmake: using ${ZEPHYR_BASE} instead of $ENV{ZEPHYR_BASE} With the introduction of ZephyrConfig.cmake all parts of CMake code should rely on the CMake ZEPHYR_BASE variable instead of the environment setting. This ensures that after the first CMake invocation, then all subsequent invocation in same build folder will use same zephyr base. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-02-12 15:42:09 +01:00
set(ENV_ZEPHYR_BASE $ENV{ZEPHYR_BASE})
# This add support for old style boilerplate include.
if((NOT DEFINED ZEPHYR_BASE) AND (DEFINED ENV_ZEPHYR_BASE))
set(ZEPHYR_BASE ${ENV_ZEPHYR_BASE} CACHE PATH "Zephyr base")
endif()
cmake: introduction of ZephyrBuildConfiguration package The ZephyrBuildConfiguration package allow downstream users to control the Zephyr build system using a cmake package. A Zephyr Build Configuration package allows for setting of additional DTS_ROOT, BOARD_ROOT, and similar variables without having to patch Zephyr repo, but it also allows for inclusion of additional boilerplate code for more advanced use cases. The repository or folder containing the Zephyr Build Configuration package must be on toplevel in the Zephyr workspace. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-05-13 23:05:28 +02:00
find_package(ZephyrBuildConfiguration NAMES ZephyrBuild PATHS ${ZEPHYR_BASE}/../* QUIET NO_DEFAULT_PATH NO_POLICY_SCOPE)
cmake: warn if inconsistency between CMAKE_SOURCE_DIR and ZEPHYR_BASE cmake has a number of issues dealing with symbolic links: https://gitlab.kitware.com/cmake/cmake/issues/16228 One of them can cause cmake to rewrite the -S input from the user and CMAKE_SOURCE_DIR to unexpectedly include symbolic links: https://cmake.org/pipermail/cmake/2019-May/thread.html#69496 Catch this corner case and warn about subtle issues like breaking -fmacro-prefix-map=${ZEPHYR_BASE}= Sample warning message: CMake Warning at ../../CMakeLists.txt:30 (message): ZEPHYR_BASE doesn't match CMAKE_CURRENT_SOURCE_DIR ZEPHYR_BASE = ~/zephyrproject/zephyr PWD = ~/westsymlink/zephyr/samples/hello_world CMAKE_CURRENT_SOURCE_DIR = ~/westsymlink/zephyr You may be using a mix of symbolic links and real paths which causes subtle and hard to debug CMake issues. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-01 00:37:40 +02:00
# Note any later project() resets PROJECT_SOURCE_DIR
cmake: using ${ZEPHYR_BASE} instead of $ENV{ZEPHYR_BASE} With the introduction of ZephyrConfig.cmake all parts of CMake code should rely on the CMake ZEPHYR_BASE variable instead of the environment setting. This ensures that after the first CMake invocation, then all subsequent invocation in same build folder will use same zephyr base. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-02-12 15:42:09 +01:00
file(TO_CMAKE_PATH "${ZEPHYR_BASE}" PROJECT_SOURCE_DIR)
cmake: boilerplate: Fix ZEPHYR_BASE variable for windows In windows an additional / is added when using zephyr-env.cmd this causes a build error in some scenarios. It also creates ugly file paths. Signed-off-by: Sigvart Hovland <sigvart.hovland@nordicsemi.no>
2019-04-12 12:17:14 +02:00
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(ZEPHYR_BINARY_DIR ${PROJECT_BINARY_DIR})
set(AUTOCONF_H ${__build_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})
cmake: boilerplate: Move out finding git+python to separate cmake files Follow the same convention as that of ccache. Improve readability of boilerplate.cmake file. Move inclusion of version.cmake up to satisfy git.cmake dependency. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-11-26 23:39:51 +01:00
#
# Import more CMake functions and macros
#
cmake: Fix python version detection The 'FindPythonInterp' that is distributed with CMake 3.8 is affected by bug: https://github.com/zephyrproject-rtos/zephyr/issues/11103 To work around this, until we upgrade to 3.13, we copy and patch the 3.8 version of 'FindPythonInterp' into the Zephyr repository. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-11-12 15:57:19 +01:00
cmake: boilerplate: move compiler-flag checks into boilerplate CheckCCompilerFlag and CheckCXXCompilerFlag does not belong to extensions.cmake since they are standard CMake files. Boilerplate seems more appropriate. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-11-26 23:19:26 +01:00
include(CheckCCompilerFlag)
include(CheckCXXCompilerFlag)
cmake: Fix python version detection The 'FindPythonInterp' that is distributed with CMake 3.8 is affected by bug: https://github.com/zephyrproject-rtos/zephyr/issues/11103 To work around this, until we upgrade to 3.13, we copy and patch the 3.8 version of 'FindPythonInterp' into the Zephyr repository. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-11-12 15:57:19 +01:00
include(${ZEPHYR_BASE}/cmake/extensions.cmake)
cmake: boilerplate: Move out finding git+python to separate cmake files Follow the same convention as that of ccache. Improve readability of boilerplate.cmake file. Move inclusion of version.cmake up to satisfy git.cmake dependency. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-11-26 23:39:51 +01:00
include(${ZEPHYR_BASE}/cmake/version.cmake) # depends on hex.cmake
#
# Find tools
#
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: boilerplate: Move out finding git+python to separate cmake files Follow the same convention as that of ccache. Improve readability of boilerplate.cmake file. Move inclusion of version.cmake up to satisfy git.cmake dependency. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-11-26 23:39:51 +01:00
include(${ZEPHYR_BASE}/cmake/python.cmake)
modules: adding support for ROOTs definitions in zephyr/module.yml Fixes: #25215 This commit introduces the possibility of defining ROOTs in a Zephyr module and have it automatically appended to list of other ROOTs. Supported with this commit: - BOARD_ROOT - SOC_ROOT - DTS_ROOT - ARCH_ROOT In order to support this in Zephyr module files, the detection of west has been moved to dedicated west.cmake file and included immediately after python.cmake. Also the inclusion of zephyr_modules.cmake has moved before first use of BOARD_ROOT. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-07-07 17:29:56 +02:00
include(${ZEPHYR_BASE}/cmake/west.cmake)
cmake: boilerplate: Move out finding git+python to separate cmake files Follow the same convention as that of ccache. Improve readability of boilerplate.cmake file. Move inclusion of version.cmake up to satisfy git.cmake dependency. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-11-26 23:39:51 +01:00
include(${ZEPHYR_BASE}/cmake/git.cmake) # depends on version.cmake
cmake: Find out earlier whether ccache is to be used or not Moving the ccache build script earlier in allows us to export ccache to external projects. Using ccache with external projects, such as OpenThread, can significantly speed up the build time. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-02-26 13:49:54 +01:00
include(${ZEPHYR_BASE}/cmake/ccache.cmake)
cmake: zephyr_module.cmake ZEPHYR_EXTRA_MODULES evaluated too late Previously, `cmake/app/boilerplate.cmake` evaluated ZEPHYR_EXTRA_MODULES on line ~548 *after* `zephyr_module.cmake` was included on line ~168. This change ensures that modules defined in `ENV{ZEPHYR_EXTRA_MODULES}` are processed properly through `zephyr_module.cmake`. Fixes #30673 Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
2020-12-12 20:13:17 +01:00
if(ZEPHYR_EXTRA_MODULES)
# ZEPHYR_EXTRA_MODULES has either been specified on the cmake CLI or is
# already in the CMakeCache.txt. This has precedence over the environment
# variable ZEPHYR_EXTRA_MODULES
elseif(DEFINED ENV{ZEPHYR_EXTRA_MODULES})
set(ZEPHYR_EXTRA_MODULES $ENV{ZEPHYR_EXTRA_MODULES})
endif()
modules: adding support for ROOTs definitions in zephyr/module.yml Fixes: #25215 This commit introduces the possibility of defining ROOTs in a Zephyr module and have it automatically appended to list of other ROOTs. Supported with this commit: - BOARD_ROOT - SOC_ROOT - DTS_ROOT - ARCH_ROOT In order to support this in Zephyr module files, the detection of west has been moved to dedicated west.cmake file and included immediately after python.cmake. Also the inclusion of zephyr_modules.cmake has moved before first use of BOARD_ROOT. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-07-07 17:29:56 +02:00
#
# Find Zephyr modules.
# Those may contain additional DTS, BOARD, SOC, ARCH ROOTs.
# Also create the Kconfig binary dir for generated Kconf files.
#
set(KCONFIG_BINARY_DIR ${CMAKE_BINARY_DIR}/Kconfig)
file(MAKE_DIRECTORY ${KCONFIG_BINARY_DIR})
include(${ZEPHYR_BASE}/cmake/zephyr_module.cmake)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
if(${CMAKE_CURRENT_SOURCE_DIR} STREQUAL ${CMAKE_CURRENT_BINARY_DIR})
message(FATAL_ERROR "Source directory equals build directory.\
In-source builds are not supported.\
Please specify a build directory, e.g. cmake -Bbuild -H.")
endif()
add_custom_target(
pristine
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
COMMAND ${CMAKE_COMMAND} -P ${ZEPHYR_BASE}/cmake/pristine.cmake
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# Equivalent to rm -rf build/*
)
cmake: Add function for adding snippets to the linker file Allows snippets to be placed in different locations: - The noinit, rwdata and rodata output sections - Two different locations for placing custom output sections, one location for RAM and another for all other sections. Signed-off-by: Øyvind Rønningstad <oyvind.ronningstad@nordicsemi.no>
2019-03-06 17:28:05 +01:00
# Dummy add to generate files.
zephyr_linker_sources(SECTIONS)
cmake: cleanup board and shield cmake code Cleanup board and shield cmake code so that code duplication is reduced. Before this commit, the code for verifying if BOARD or SHIELD user input had changed was almost identical. The common code has been made into a Zephyr extension function so that all part of Zephyr build system can have a uniform way of checking if sticky arguments has changed, and print user warning in a uniform way. This also fixes an undiscovered flaw, where changing a shield is not possible if a shield was defined at first CMake invocation, but in case no shield had been specified at all, then build system would wrongly allow specifying and changing shields, for example doing: cmake -DBOARD=nrf52840dk_nrf52840 -DSHIELD=sparkfun_sara_r4 <sample> cmake -DSHIELD=wnc_m14a2a results correctly in: > CMake Warning at zephyr/cmake/app/boilerplate.cmake:287 (message): > The build directory must be cleaned pristinely when changing shields and correctly keep existing SHIELD settings. but doing: cmake -DBOARD=nrf52840dk_nrf52840 <sample> cmake -DSHIELD=sparkfun_sara_r4 cmake -DSHIELD=wnc_m14a2a would not result in any warning, because `CACHED_SHIELD` was not correctly checked in this case. Changing shield is not a supported feature as it have unknown behavior. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-11-10 13:42:32 +01:00
# Check that BOARD has been provided, and that it has not changed.
zephyr_check_cache(BOARD REQUIRED)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: print shields together with board Currently only BOARD is printed when running CMake. This commit prints shields together with board, if one or more shields are specified. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-11-10 13:57:24 +01:00
set(BOARD_MESSAGE "Board: ${BOARD}")
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: add support for user-defined board aliases Zephyr board names must be globally unique which requires that they encode all necessary information to identify a specific target. Typing in these names can be inconvenient to developers working on multiple targets within a single workspace. Extend the cmake infrastructure to read an optional board aliases file that will map custom aliases to the corresponding canonical Zephyr board name. Signed-off-by: Peter A. Bigot <pab@pabigot.com>
2020-04-04 15:29:30 +02:00
if(DEFINED ENV{ZEPHYR_BOARD_ALIASES})
include($ENV{ZEPHYR_BOARD_ALIASES})
if(${BOARD}_BOARD_ALIAS)
set(BOARD_ALIAS ${BOARD} CACHE STRING "Board alias, provided by user")
set(BOARD ${${BOARD}_BOARD_ALIAS})
message(STATUS "Aliased BOARD=${BOARD_ALIAS} changed to ${BOARD}")
endif()
endif()
cmake: deprecation of board names This commit introduces boards/deprecated.cmake to allow deprecation of existing boards, when a board is renamed. This allows users to still specify the old board name, and let Zephyr build system to select the new board name. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-03-16 15:36:52 +01:00
include(${ZEPHYR_BASE}/boards/deprecated.cmake)
if(${BOARD}_DEPRECATED)
set(BOARD_DEPRECATED ${BOARD} CACHE STRING "Deprecated board name, provided by user")
set(BOARD ${${BOARD}_DEPRECATED})
message(WARNING "Deprecated BOARD=${BOARD_DEPRECATED} name specified, board automatically changed to: ${BOARD}.")
endif()
cmake: cleanup board and shield cmake code Cleanup board and shield cmake code so that code duplication is reduced. Before this commit, the code for verifying if BOARD or SHIELD user input had changed was almost identical. The common code has been made into a Zephyr extension function so that all part of Zephyr build system can have a uniform way of checking if sticky arguments has changed, and print user warning in a uniform way. This also fixes an undiscovered flaw, where changing a shield is not possible if a shield was defined at first CMake invocation, but in case no shield had been specified at all, then build system would wrongly allow specifying and changing shields, for example doing: cmake -DBOARD=nrf52840dk_nrf52840 -DSHIELD=sparkfun_sara_r4 <sample> cmake -DSHIELD=wnc_m14a2a results correctly in: > CMake Warning at zephyr/cmake/app/boilerplate.cmake:287 (message): > The build directory must be cleaned pristinely when changing shields and correctly keep existing SHIELD settings. but doing: cmake -DBOARD=nrf52840dk_nrf52840 <sample> cmake -DSHIELD=sparkfun_sara_r4 cmake -DSHIELD=wnc_m14a2a would not result in any warning, because `CACHED_SHIELD` was not correctly checked in this case. Changing shield is not a supported feature as it have unknown behavior. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-11-10 13:42:32 +01:00
# Check that SHIELD has not changed.
zephyr_check_cache(SHIELD)
cmake: dts: move to specifying shield on the command line Rather than specifying SHIELD via Kconfig, we move it to being specified via the command line, similar to board. So we can do: -DSHIELD=x_nucleo_iks01a1 or, for multiple shields: -DSHIELD="x_nucleo_iks01a1 frdm_kw41z" Following cmake change, update x_nucleo_iks01a1 sample in order not to enable CONFIG option anymore but set SHIELD cmake option. Last, update documentation to reflect this change. Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-01-14 16:11:15 +01:00
cmake: print shields together with board Currently only BOARD is printed when running CMake. This commit prints shields together with board, if one or more shields are specified. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-11-10 13:57:24 +01:00
if(SHIELD)
set(BOARD_MESSAGE "${BOARD_MESSAGE}, Shield(s): ${SHIELD}")
endif()
message(STATUS "${BOARD_MESSAGE}")
cmake: Fall back to ZEPHYR_BASE when the board is not in BOARD_ROOT It is very inconvenient to maintain an application that both runs on a Zephyr board and an out-of-tree board. It forces one to write build scripts like this in the app: if(BOARD STREQUAL my_out_of_tree_board) set(BOARD_ROOT some/out/of/tree/board/path) endif() To avoid this we change the semantics of BOARD_ROOT. Instead of it being a path to the board root it is now a prioritized list of board root directories. Zephyr will append ZEPHYR_BASE to BOARD_ROOT. This ensures that Zephyr boards can be used when the out-of-tree board directory can not supply the requested board. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-27 18:10:22 +02:00
# 'BOARD_ROOT' is a prioritized list of directories where boards may
# be found. It always includes ${ZEPHYR_BASE} at the lowest priority.
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 BOARD_ROOT)
cmake: Fall back to ZEPHYR_BASE when the board is not in BOARD_ROOT It is very inconvenient to maintain an application that both runs on a Zephyr board and an out-of-tree board. It forces one to write build scripts like this in the app: if(BOARD STREQUAL my_out_of_tree_board) set(BOARD_ROOT some/out/of/tree/board/path) endif() To avoid this we change the semantics of BOARD_ROOT. Instead of it being a path to the board root it is now a prioritized list of board root directories. Zephyr will append ZEPHYR_BASE to BOARD_ROOT. This ensures that Zephyr boards can be used when the out-of-tree board directory can not supply the requested board. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-27 18:10:22 +02:00
list(APPEND BOARD_ROOT ${ZEPHYR_BASE})
build: support out of tree SoC definition Add the glue to make this work with SoC code outside of the tree. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-04 21:34:06 +02:00
cmake: kconfig: support for multiple SOC_ROOT This commit introduces support for multiple SOC_ROOT. This means that additional SOC_ROOTs specified using -DSOC_ROOT as argument to CMake will be forming a list together with ${ZEPHYR_BASE}. This allows for greater flexibility, as developers can now specify multiple out-of-tree SoCs and not worry about the SoC used for the board they compile for. Also it avoid code, such as: if(BOARD STREQUAL my_board_using_out_of_tree_soc) set(SOC_ROOT some/out/of/tree/soc/path) endif() in application CMakeLists.txt. Finally, allowing multiple SOC_ROOTs prepares for specifying SOC_ROOTs in Zephyr modules. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-07-06 12:53:39 +02:00
# 'SOC_ROOT' is a prioritized list of directories where socs may be
# found. It always includes ${ZEPHYR_BASE}/soc at the lowest priority.
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 SOC_ROOT)
cmake: kconfig: support for multiple SOC_ROOT This commit introduces support for multiple SOC_ROOT. This means that additional SOC_ROOTs specified using -DSOC_ROOT as argument to CMake will be forming a list together with ${ZEPHYR_BASE}. This allows for greater flexibility, as developers can now specify multiple out-of-tree SoCs and not worry about the SoC used for the board they compile for. Also it avoid code, such as: if(BOARD STREQUAL my_board_using_out_of_tree_soc) set(SOC_ROOT some/out/of/tree/soc/path) endif() in application CMakeLists.txt. Finally, allowing multiple SOC_ROOTs prepares for specifying SOC_ROOTs in Zephyr modules. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-07-06 12:53:39 +02:00
list(APPEND SOC_ROOT ${ZEPHYR_BASE})
build: support out-of-tree custom boards This is one way we can support out of tree board definitions. Basically all this needs is a board definition in the application source directory that follows the same structure we have in the main Zephyr tree (also allowing multiple custom boards). An application tree would look like this for example: boards/ CMakeLists.txt prj.conf README.rst src/ with boards following the same structure as in Zephyr: . ├── boards │   └── x86 │   └── arduino_101 │   ├── doc │   │   └── img │   └── support └── src To use this, you need to specify the BOARD_ROOT variable on the command line when building: cmake -DBOARD=<board name> -DBOARD_ROOT=<path to boards> .. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-02-12 05:30:57 +01:00
cmake: allowing list of ARCH_ROOTs This commit aligns ARCH_ROOT to conform to BOARD_ROOT, DTS_ROOT, SOC_ROOT that all allows list of directories. Also it avoid code, such as: if(BOARD STREQUAL my_board_using_out_of_tree_arch) set(ARCH_ROOT some/out/of/tree/arch/path) endif() in application CMakeLists.txt. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-07-07 08:58:14 +02:00
# 'ARCH_ROOT' is a prioritized list of directories where archs may be
# found. It always includes ${ZEPHYR_BASE} at the lowest priority.
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 ARCH_ROOT)
cmake: allowing list of ARCH_ROOTs This commit aligns ARCH_ROOT to conform to BOARD_ROOT, DTS_ROOT, SOC_ROOT that all allows list of directories. Also it avoid code, such as: if(BOARD STREQUAL my_board_using_out_of_tree_arch) set(ARCH_ROOT some/out/of/tree/arch/path) endif() in application CMakeLists.txt. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-07-07 08:58:14 +02:00
list(APPEND ARCH_ROOT ${ZEPHYR_BASE})
Build: Added support for out-of-tree Arch Introduces the ARCH_ROOT argument, similar to BOARD_ROOT and SOC_ROOT. This enables support for out-of-tree architectures. The ARCH_ROOT out-of-tree layout is expected to be the following: * ${ARCH_ROOT}/arch/${ARCH}/ * ${ARCH_ROOT}/include/arch/${ARCH}/ (Optional) Signed-off-by: Klaus Petersen <kape@oticon.com>
2018-11-15 10:37:46 +01:00
cmake: resolved list issue when parsing shield list Fixes: #25656 The commit a8e90cbfb30489c24139244dc3218c81c0950224 improved handling of shields. Unfortunately it pops items from the SHIELD variable which works well if SHIELD is a CMake ;-separated list, but if the list is a space separated list, as may be provided by the user, then this principle fails as reported in #25656. This is fixed by keeping improved behaviour, while popping from an alternative SHIELD-NOTFOUND list instead. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-05-28 18:06:27 +02:00
if(DEFINED SHIELD)
string(REPLACE " " ";" SHIELD_AS_LIST "${SHIELD}")
endif()
# SHIELD-NOTFOUND is a real CMake list, from which valid shields can be popped.
# After processing all shields, only invalid shields will be left in this list.
set(SHIELD-NOTFOUND ${SHIELD_AS_LIST})
cmake: Fall back to ZEPHYR_BASE when the board is not in BOARD_ROOT It is very inconvenient to maintain an application that both runs on a Zephyr board and an out-of-tree board. It forces one to write build scripts like this in the app: if(BOARD STREQUAL my_out_of_tree_board) set(BOARD_ROOT some/out/of/tree/board/path) endif() To avoid this we change the semantics of BOARD_ROOT. Instead of it being a path to the board root it is now a prioritized list of board root directories. Zephyr will append ZEPHYR_BASE to BOARD_ROOT. This ensures that Zephyr boards can be used when the out-of-tree board directory can not supply the requested board. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-27 18:10:22 +02:00
# Use BOARD to search for a '_defconfig' file.
# e.g. zephyr/boards/arm/96b_carbon_nrf51/96b_carbon_nrf51_defconfig.
# When found, use that path to infer the ARCH we are building for.
foreach(root ${BOARD_ROOT})
# NB: find_path will return immediately if the output variable is
# already set
cmake: board alias message when hiding existing board This commit will print a CMake notice if a user defines a board alias that is identical to an existing board name. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-04-07 15:43:31 +02:00
if (BOARD_ALIAS)
find_path(BOARD_HIDDEN_DIR
NAMES ${BOARD_ALIAS}_defconfig
PATHS ${root}/boards/*/*
NO_DEFAULT_PATH
)
if(BOARD_HIDDEN_DIR)
message("Board alias ${BOARD_ALIAS} is hiding the real board of same name")
endif()
endif()
cmake: Fall back to ZEPHYR_BASE when the board is not in BOARD_ROOT It is very inconvenient to maintain an application that both runs on a Zephyr board and an out-of-tree board. It forces one to write build scripts like this in the app: if(BOARD STREQUAL my_out_of_tree_board) set(BOARD_ROOT some/out/of/tree/board/path) endif() To avoid this we change the semantics of BOARD_ROOT. Instead of it being a path to the board root it is now a prioritized list of board root directories. Zephyr will append ZEPHYR_BASE to BOARD_ROOT. This ensures that Zephyr boards can be used when the out-of-tree board directory can not supply the requested board. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-27 18:10:22 +02:00
find_path(BOARD_DIR
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
NAMES ${BOARD}_defconfig
PATHS ${root}/boards/*/*
NO_DEFAULT_PATH
)
cmake: Fall back to ZEPHYR_BASE when the board is not in BOARD_ROOT It is very inconvenient to maintain an application that both runs on a Zephyr board and an out-of-tree board. It forces one to write build scripts like this in the app: if(BOARD STREQUAL my_out_of_tree_board) set(BOARD_ROOT some/out/of/tree/board/path) endif() To avoid this we change the semantics of BOARD_ROOT. Instead of it being a path to the board root it is now a prioritized list of board root directories. Zephyr will append ZEPHYR_BASE to BOARD_ROOT. This ensures that Zephyr boards can be used when the out-of-tree board directory can not supply the requested board. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-27 18:10:22 +02:00
if(BOARD_DIR AND NOT (${root} STREQUAL ${ZEPHYR_BASE}))
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
set(USING_OUT_OF_TREE_BOARD 1)
cmake: Fall back to ZEPHYR_BASE when the board is not in BOARD_ROOT It is very inconvenient to maintain an application that both runs on a Zephyr board and an out-of-tree board. It forces one to write build scripts like this in the app: if(BOARD STREQUAL my_out_of_tree_board) set(BOARD_ROOT some/out/of/tree/board/path) endif() To avoid this we change the semantics of BOARD_ROOT. Instead of it being a path to the board root it is now a prioritized list of board root directories. Zephyr will append ZEPHYR_BASE to BOARD_ROOT. This ensures that Zephyr boards can be used when the out-of-tree board directory can not supply the requested board. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-27 18:10:22 +02:00
endif()
cmake: dts: move to specifying shield on the command line Rather than specifying SHIELD via Kconfig, we move it to being specified via the command line, similar to board. So we can do: -DSHIELD=x_nucleo_iks01a1 or, for multiple shields: -DSHIELD="x_nucleo_iks01a1 frdm_kw41z" Following cmake change, update x_nucleo_iks01a1 sample in order not to enable CONFIG option anymore but set SHIELD cmake option. Last, update documentation to reflect this change. Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-01-14 16:11:15 +01:00
set(shield_dir ${root}/boards/shields)
# Match the .overlay files in the shield directories to make sure we are
# finding shields, e.g. x_nucleo_iks01a1/x_nucleo_iks01a1.overlay
file(GLOB_RECURSE shields_refs_list
RELATIVE ${shield_dir}
${shield_dir}/*/*.overlay
)
# The above gives a list like
# x_nucleo_iks01a1/x_nucleo_iks01a1.overlay;x_nucleo_iks01a2/x_nucleo_iks01a2.overlay
# we construct a list of shield names by extracting file name and
# removing the extension.
cmake: Fixes for shields in multiple roots * Reset SHIELD_LIST on each root loop, to avoid matching on shields from the previous iteration of the loop. Signed-off-by: Pete Johanson <peter@peterjohanson.com>
2020-05-28 18:51:17 +02:00
unset(SHIELD_LIST)
cmake: dts: move to specifying shield on the command line Rather than specifying SHIELD via Kconfig, we move it to being specified via the command line, similar to board. So we can do: -DSHIELD=x_nucleo_iks01a1 or, for multiple shields: -DSHIELD="x_nucleo_iks01a1 frdm_kw41z" Following cmake change, update x_nucleo_iks01a1 sample in order not to enable CONFIG option anymore but set SHIELD cmake option. Last, update documentation to reflect this change. Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-01-14 16:11:15 +01:00
foreach(shield_path ${shields_refs_list})
get_filename_component(shield ${shield_path} NAME_WE)
list(APPEND SHIELD_LIST ${shield})
endforeach()
if(DEFINED SHIELD)
foreach(s ${SHIELD_AS_LIST})
list(FIND SHIELD_LIST ${s} _idx)
cmake: Fix shield bug when BOARD_ROOT is a list Fix bug where SHIELDS would be marked as "not found" in the NOT_FOUND_SHIELD_LIST when they were present, just not in the first BOARD root in the BOARD_ROOT list. Instead of marking shields in the NOT_FOUND_SHIELD_LIST, we (continue) popping shields from SHIELD and check if there are any shields left in SHIELD. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2020-03-19 16:45:53 +01:00
if (_idx EQUAL -1)
continue()
endif()
cmake: dts: move to specifying shield on the command line Rather than specifying SHIELD via Kconfig, we move it to being specified via the command line, similar to board. So we can do: -DSHIELD=x_nucleo_iks01a1 or, for multiple shields: -DSHIELD="x_nucleo_iks01a1 frdm_kw41z" Following cmake change, update x_nucleo_iks01a1 sample in order not to enable CONFIG option anymore but set SHIELD cmake option. Last, update documentation to reflect this change. Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-01-14 16:11:15 +01:00
cmake: resolved list issue when parsing shield list Fixes: #25656 The commit a8e90cbfb30489c24139244dc3218c81c0950224 improved handling of shields. Unfortunately it pops items from the SHIELD variable which works well if SHIELD is a CMake ;-separated list, but if the list is a space separated list, as may be provided by the user, then this principle fails as reported in #25656. This is fixed by keeping improved behaviour, while popping from an alternative SHIELD-NOTFOUND list instead. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-05-28 18:06:27 +02:00
list(REMOVE_ITEM SHIELD-NOTFOUND ${s})
cmake: Fix shield bug when BOARD_ROOT is a list Fix bug where SHIELDS would be marked as "not found" in the NOT_FOUND_SHIELD_LIST when they were present, just not in the first BOARD root in the BOARD_ROOT list. Instead of marking shields in the NOT_FOUND_SHIELD_LIST, we (continue) popping shields from SHIELD and check if there are any shields left in SHIELD. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2020-03-19 16:45:53 +01:00
list(GET shields_refs_list ${_idx} s_path)
get_filename_component(s_dir ${s_path} DIRECTORY)
Revert "shields: Modify overlay file order" Fixes: #29074 This reverts commit fc8f639b9a6df12a024b0ee5b452db06d7b72609. The suggestion provided in #27901 is impacting processing order of overlay files in a non-logical way, see #29074 discussion for details. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-11-05 15:24:13 +01:00
# if shield config flag is on, add shield overlay to the shield overlays
# list and dts_fixup file to the shield fixup file
list(APPEND
shield_dts_files
${shield_dir}/${s_path}
)
list(APPEND
shield_dts_fixups
${shield_dir}/${s_dir}/dts_fixup.h
)
cmake: Fix shield bug when BOARD_ROOT is a list Fix bug where SHIELDS would be marked as "not found" in the NOT_FOUND_SHIELD_LIST when they were present, just not in the first BOARD root in the BOARD_ROOT list. Instead of marking shields in the NOT_FOUND_SHIELD_LIST, we (continue) popping shields from SHIELD and check if there are any shields left in SHIELD. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2020-03-19 16:45:53 +01:00
# search for shield/boards/board.overlay file
if(EXISTS ${shield_dir}/${s_dir}/boards/${BOARD}.overlay)
# add shield/board overlay to the shield overlays list
list(APPEND
shield_dts_files
${shield_dir}/${s_dir}/boards/${BOARD}.overlay
cmake: move shield board/conf handling Move handling for shield boards/board.overlay, shield.conf and boards/board.conf inside the SHIELD_LIST check. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-09-11 19:06:43 +02:00
)
cmake: Fix shield bug when BOARD_ROOT is a list Fix bug where SHIELDS would be marked as "not found" in the NOT_FOUND_SHIELD_LIST when they were present, just not in the first BOARD root in the BOARD_ROOT list. Instead of marking shields in the NOT_FOUND_SHIELD_LIST, we (continue) popping shields from SHIELD and check if there are any shields left in SHIELD. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2020-03-19 16:45:53 +01:00
endif()
# search for shield/boards/shield/board.overlay file
if(EXISTS ${shield_dir}/${s_dir}/boards/${s}/${BOARD}.overlay)
# add shield/board overlay to the shield overlays list
list(APPEND
shield_dts_files
${shield_dir}/${s_dir}/boards/${s}/${BOARD}.overlay
cmake: add new search locations for shield overlay and conf files * Add support to search for a board specific shield in <SHIELD DIR>/boards/<SHIELD>/<BOARD>.{overlay,conf}. So we can support something like: x_nucleo_iks01a3/boards/x_nucleo_iks01a3_shub/stm32mp157c_dk2.overlay x_nucleo_iks01a3/boards/x_nucleo_iks01a3_shub/stm32mp157c_dk2.conf Fixes #19078 Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-09-11 17:14:25 +02:00
)
cmake: Fix shield bug when BOARD_ROOT is a list Fix bug where SHIELDS would be marked as "not found" in the NOT_FOUND_SHIELD_LIST when they were present, just not in the first BOARD root in the BOARD_ROOT list. Instead of marking shields in the NOT_FOUND_SHIELD_LIST, we (continue) popping shields from SHIELD and check if there are any shields left in SHIELD. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2020-03-19 16:45:53 +01:00
endif()
# search for shield/shield.conf file
if(EXISTS ${shield_dir}/${s_dir}/${s}.conf)
# add shield.conf to the shield config list
list(APPEND
shield_conf_files
${shield_dir}/${s_dir}/${s}.conf
cmake: move shield board/conf handling Move handling for shield boards/board.overlay, shield.conf and boards/board.conf inside the SHIELD_LIST check. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-09-11 19:06:43 +02:00
)
cmake: Fix shield bug when BOARD_ROOT is a list Fix bug where SHIELDS would be marked as "not found" in the NOT_FOUND_SHIELD_LIST when they were present, just not in the first BOARD root in the BOARD_ROOT list. Instead of marking shields in the NOT_FOUND_SHIELD_LIST, we (continue) popping shields from SHIELD and check if there are any shields left in SHIELD. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2020-03-19 16:45:53 +01:00
endif()
# search for shield/boards/board.conf file
if(EXISTS ${shield_dir}/${s_dir}/boards/${BOARD}.conf)
# add HW specific board.conf to the shield config list
list(APPEND
shield_conf_files
${shield_dir}/${s_dir}/boards/${BOARD}.conf
cmake: move shield board/conf handling Move handling for shield boards/board.overlay, shield.conf and boards/board.conf inside the SHIELD_LIST check. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-09-11 19:06:43 +02:00
)
cmake: Fix shield bug when BOARD_ROOT is a list Fix bug where SHIELDS would be marked as "not found" in the NOT_FOUND_SHIELD_LIST when they were present, just not in the first BOARD root in the BOARD_ROOT list. Instead of marking shields in the NOT_FOUND_SHIELD_LIST, we (continue) popping shields from SHIELD and check if there are any shields left in SHIELD. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2020-03-19 16:45:53 +01:00
endif()
# search for shield/boards/shield/board.conf file
if(EXISTS ${shield_dir}/${s_dir}/boards/${s}/${BOARD}.conf)
# add HW specific board.conf to the shield config list
list(APPEND
shield_conf_files
${shield_dir}/${s_dir}/boards/${s}/${BOARD}.conf
cmake: add new search locations for shield overlay and conf files * Add support to search for a board specific shield in <SHIELD DIR>/boards/<SHIELD>/<BOARD>.{overlay,conf}. So we can support something like: x_nucleo_iks01a3/boards/x_nucleo_iks01a3_shub/stm32mp157c_dk2.overlay x_nucleo_iks01a3/boards/x_nucleo_iks01a3_shub/stm32mp157c_dk2.conf Fixes #19078 Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-09-11 17:14:25 +02:00
)
cmake: dts: move to specifying shield on the command line Rather than specifying SHIELD via Kconfig, we move it to being specified via the command line, similar to board. So we can do: -DSHIELD=x_nucleo_iks01a1 or, for multiple shields: -DSHIELD="x_nucleo_iks01a1 frdm_kw41z" Following cmake change, update x_nucleo_iks01a1 sample in order not to enable CONFIG option anymore but set SHIELD cmake option. Last, update documentation to reflect this change. Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-01-14 16:11:15 +01:00
endif()
endforeach()
endif()
cmake: Fall back to ZEPHYR_BASE when the board is not in BOARD_ROOT It is very inconvenient to maintain an application that both runs on a Zephyr board and an out-of-tree board. It forces one to write build scripts like this in the app: if(BOARD STREQUAL my_out_of_tree_board) set(BOARD_ROOT some/out/of/tree/board/path) endif() To avoid this we change the semantics of BOARD_ROOT. Instead of it being a path to the board root it is now a prioritized list of board root directories. Zephyr will append ZEPHYR_BASE to BOARD_ROOT. This ensures that Zephyr boards can be used when the out-of-tree board directory can not supply the requested board. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-27 18:10:22 +02:00
endforeach()
cmake: Show usage when an invalid board is given Print the usage when an invalid board is given, this somewhat allievates the catch-22 where you need to run CMake to know what boards exist, but you need a board to run CMake. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-06 13:56:12 +01:00
cmake: Don't remember misnamed boards CMake prints a helpful error message with all the boards supported when a board name has been misspelled. But CMake also remembers (caches) the corrupted board name and refuses to change it until the board directory has been cleared. CMake is rightly hesitant to change the board, as other cached variables depend on what the board is. But it is safe to change the board just after it has been selected, because we verify it's correctness before using it to calculate other variables. So to support the use-case of changing a misspelled board name (without clearing the build directory) we unset the cached board when it is invalid. Also; change the now unused (in-tree) macro 'assert_with_usage' to 'print_usage'. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-11-19 11:56:19 +01:00
if(NOT BOARD_DIR)
message("No board named '${BOARD}' found")
print_usage()
unset(CACHED_BOARD CACHE)
message(FATAL_ERROR "Invalid usage")
endif()
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: resolved list issue when parsing shield list Fixes: #25656 The commit a8e90cbfb30489c24139244dc3218c81c0950224 improved handling of shields. Unfortunately it pops items from the SHIELD variable which works well if SHIELD is a CMake ;-separated list, but if the list is a space separated list, as may be provided by the user, then this principle fails as reported in #25656. This is fixed by keeping improved behaviour, while popping from an alternative SHIELD-NOTFOUND list instead. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-05-28 18:06:27 +02:00
if(DEFINED SHIELD AND NOT (SHIELD-NOTFOUND STREQUAL ""))
foreach (s ${SHIELD-NOTFOUND})
cmake: dts: move to specifying shield on the command line Rather than specifying SHIELD via Kconfig, we move it to being specified via the command line, similar to board. So we can do: -DSHIELD=x_nucleo_iks01a1 or, for multiple shields: -DSHIELD="x_nucleo_iks01a1 frdm_kw41z" Following cmake change, update x_nucleo_iks01a1 sample in order not to enable CONFIG option anymore but set SHIELD cmake option. Last, update documentation to reflect this change. Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-01-14 16:11:15 +01:00
message("No shield named '${s}' found")
endforeach()
print_usage()
unset(CACHED_SHIELD CACHE)
message(FATAL_ERROR "Invalid usage")
endif()
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
get_filename_component(BOARD_ARCH_DIR ${BOARD_DIR} DIRECTORY)
cmake: Misc. cleanups of how BOARD_ROOT and BOARD_DIR are used Misc. refactorings that clean up how BOARD_ROOT and BOARD_DIR are used. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-09-27 17:15:24 +02:00
get_filename_component(ARCH ${BOARD_ARCH_DIR} NAME)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: allowing list of ARCH_ROOTs This commit aligns ARCH_ROOT to conform to BOARD_ROOT, DTS_ROOT, SOC_ROOT that all allows list of directories. Also it avoid code, such as: if(BOARD STREQUAL my_board_using_out_of_tree_arch) set(ARCH_ROOT some/out/of/tree/arch/path) endif() in application CMakeLists.txt. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-07-07 08:58:14 +02:00
foreach(root ${ARCH_ROOT})
if(EXISTS ${root}/arch/${ARCH}/CMakeLists.txt)
set(ARCH_DIR ${root}/arch)
break()
endif()
endforeach()
if(NOT ARCH_DIR)
message(FATAL_ERROR "Could not find ARCH=${ARCH} for BOARD=${BOARD}, \
please check your installation. ARCH roots searched: \n\
${ARCH_ROOT}")
endif()
cmake: improved handling of CONF_FILE cached variable Fixes: #28134 Minor fix for correctly testing if CONF_FILE variable is defined, and if it is defined, then a current scope variable will be set with same name. For a variable that is already present in current scope this has no effect, but a cached variable (such as one provided with -DCONF_FILE) will now have both a current scope and cached definition. This ensures that current scope CONF_FILE will continue to be defined even when the cached variable is cleared later. Clearing of the cached variable ensures correct detection if user later re-invokes CMake with a new -DCONF_FILE value. The cached version is cleared later in favor of the CACHED_CONF_FILE that is used between multiple CMake invocations. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-09-07 21:57:46 +02:00
if(DEFINED CONF_FILE)
# This ensures that CACHE{CONF_FILE} will be set correctly to current scope
# variable CONF_FILE. An already current scope variable will stay the same.
set(CONF_FILE ${CONF_FILE})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# CONF_FILE has either been specified on the cmake CLI or is already
# in the CMakeCache.txt. This has precedence over the environment
# variable CONF_FILE and the default prj.conf
cmake: extend support for conf file and board overlays Fixes: #27934 This commit introduces additional naming support of config files. It is now possible to create a config file of the form `prj_<build>.conf` and automatically have a corresponding `boards/<BOARD>_<build>.conf` config file merged. As example, one can create a structure as: |-- prj.conf |-- prj_debug.conf |-- boards |-- nrf52840dk_nrf52840.conf |-- nrf52840dk_nrf52840_debug.conf when building: (existing behavior) cmake -DBOARD=nrf52840dk_nrf52840 ... prj.conf is merged with nrf52840dk_nrf52840.conf when building: (new behavior) cmake -DBOARD=nrf52840dk_nrf52840 -DCONF_FILE=prj_debug.conf ... prj_debug.conf is merged with nrf52840dk_nrf52840_debug.conf Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-09-03 23:39:02 +02:00
# In order to support a `prj_<name>.conf pattern for auto inclusion of board
# overlays, then we must first ensure only a single conf file is provided.
string(REPLACE " " ";" CONF_FILE_AS_LIST "${CONF_FILE}")
list(LENGTH CONF_FILE_AS_LIST CONF_FILE_LENGTH)
if(${CONF_FILE_LENGTH} EQUAL 1)
# Need the file name to look for match.
# Need path in order to check if it is absolute.
get_filename_component(CONF_FILE_NAME ${CONF_FILE} NAME)
get_filename_component(CONF_FILE_DIR ${CONF_FILE} DIRECTORY)
cmake: fixed issue with CONF_FILE pattern when using build type This commit fixes an issue where specifying a build type config file in a subfolder named: `prj_<something>` would cause a wrong match and fail to find Kconfig fragments, as example: Working: `-DCONF_FILE=myconfigs/prj_debug.conf` would correctly add myconfigs/boards/<board>_debug.conf to list of conf files. Failing: `-DCONF_FILE=prj_configs/prj_debug.conf` would fail to locate prj_configs/boards/<board>_debug.conf, and thus the board specific config fragment was not added to the list of config files. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-11-11 15:55:56 +01:00
if(${CONF_FILE_NAME} MATCHES "prj_(.*).conf")
cmake: extend support for conf file and board overlays Fixes: #27934 This commit introduces additional naming support of config files. It is now possible to create a config file of the form `prj_<build>.conf` and automatically have a corresponding `boards/<BOARD>_<build>.conf` config file merged. As example, one can create a structure as: |-- prj.conf |-- prj_debug.conf |-- boards |-- nrf52840dk_nrf52840.conf |-- nrf52840dk_nrf52840_debug.conf when building: (existing behavior) cmake -DBOARD=nrf52840dk_nrf52840 ... prj.conf is merged with nrf52840dk_nrf52840.conf when building: (new behavior) cmake -DBOARD=nrf52840dk_nrf52840 -DCONF_FILE=prj_debug.conf ... prj_debug.conf is merged with nrf52840dk_nrf52840_debug.conf Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-09-03 23:39:02 +02:00
if(NOT IS_ABSOLUTE ${CONF_FILE_DIR})
set(CONF_FILE_DIR ${APPLICATION_SOURCE_DIR}/${CONF_FILE_DIR})
endif()
if(EXISTS ${CONF_FILE_DIR}/boards/${BOARD}_${CMAKE_MATCH_1}.conf)
list(APPEND CONF_FILE ${CONF_FILE_DIR}/boards/${BOARD}_${CMAKE_MATCH_1}.conf)
endif()
endif()
endif()
elseif(CACHED_CONF_FILE)
# Cached conf file is present.
# That value has precedence over anything else than a new
# `cmake -DCONF_FILE=<file>` invocation.
set(CONF_FILE ${CACHED_CONF_FILE})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
elseif(DEFINED ENV{CONF_FILE})
set(CONF_FILE $ENV{CONF_FILE})
elseif(COMMAND set_conf_file)
cmake: Deprecate 'set_conf_file' In-tree, all usage of 'set_conf_file' is implementing the same pattern (with some inconsequential differences). To reduce copy-paste and get closer to dropping support for 'set_conf_file', we include this pattern into the built-in set of patterns. 'set_conf_file' is causing issues for future extensions, e.g. multi-image support, and is also the source of a lot of duplicated code. Note support for 'set_conf_file' is not dropped, it is only marked as deprecated. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-28 14:53:48 +01:00
message(WARNING "'set_conf_file' is deprecated, it will be removed in a future release.")
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set_conf_file()
elseif(EXISTS ${APPLICATION_SOURCE_DIR}/prj_${BOARD}.conf)
set(CONF_FILE ${APPLICATION_SOURCE_DIR}/prj_${BOARD}.conf)
cmake: Deprecate 'set_conf_file' In-tree, all usage of 'set_conf_file' is implementing the same pattern (with some inconsequential differences). To reduce copy-paste and get closer to dropping support for 'set_conf_file', we include this pattern into the built-in set of patterns. 'set_conf_file' is causing issues for future extensions, e.g. multi-image support, and is also the source of a lot of duplicated code. Note support for 'set_conf_file' is not dropped, it is only marked as deprecated. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-28 14:53:48 +01:00
elseif(EXISTS ${APPLICATION_SOURCE_DIR}/boards/${BOARD}.conf)
set(CONF_FILE ${APPLICATION_SOURCE_DIR}/prj.conf ${APPLICATION_SOURCE_DIR}/boards/${BOARD}.conf)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
elseif(EXISTS ${APPLICATION_SOURCE_DIR}/prj.conf)
set(CONF_FILE ${APPLICATION_SOURCE_DIR}/prj.conf)
endif()
cmake: extend support for conf file and board overlays Fixes: #27934 This commit introduces additional naming support of config files. It is now possible to create a config file of the form `prj_<build>.conf` and automatically have a corresponding `boards/<BOARD>_<build>.conf` config file merged. As example, one can create a structure as: |-- prj.conf |-- prj_debug.conf |-- boards |-- nrf52840dk_nrf52840.conf |-- nrf52840dk_nrf52840_debug.conf when building: (existing behavior) cmake -DBOARD=nrf52840dk_nrf52840 ... prj.conf is merged with nrf52840dk_nrf52840.conf when building: (new behavior) cmake -DBOARD=nrf52840dk_nrf52840 -DCONF_FILE=prj_debug.conf ... prj_debug.conf is merged with nrf52840dk_nrf52840_debug.conf Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-09-03 23:39:02 +02:00
set(CACHED_CONF_FILE ${CONF_FILE} CACHE STRING "If desired, you can build the application using\
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
the configuration settings specified in an alternate .conf file using this parameter. \
These settings will override the settings in the application’s .config file or its default .conf file.\
cmake: extend support for conf file and board overlays Fixes: #27934 This commit introduces additional naming support of config files. It is now possible to create a config file of the form `prj_<build>.conf` and automatically have a corresponding `boards/<BOARD>_<build>.conf` config file merged. As example, one can create a structure as: |-- prj.conf |-- prj_debug.conf |-- boards |-- nrf52840dk_nrf52840.conf |-- nrf52840dk_nrf52840_debug.conf when building: (existing behavior) cmake -DBOARD=nrf52840dk_nrf52840 ... prj.conf is merged with nrf52840dk_nrf52840.conf when building: (new behavior) cmake -DBOARD=nrf52840dk_nrf52840 -DCONF_FILE=prj_debug.conf ... prj_debug.conf is merged with nrf52840dk_nrf52840_debug.conf Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-09-03 23:39:02 +02:00
Multiple files may be listed, e.g. CONF_FILE=\"prj1.confi;prj2.conf\" \
The CACHED_CONF_FILE is internal Zephyr variable used between CMake runs. \
To change CONF_FILE, use the CONF_FILE variable.")
unset(CONF_FILE CACHE)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: dts: Allow multiple overlay files This patch changes the manner in which we collect DTS overlay files so that they comply with the same approach taken for configuration fragment files (.conf). Additionally it also documents the usage of those files in the Application Developer Guide. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-31 18:00:49 +01:00
if(DTC_OVERLAY_FILE)
# DTC_OVERLAY_FILE has either been specified on the cmake CLI or is already
# in the CMakeCache.txt. This has precedence over the environment
# variable DTC_OVERLAY_FILE
elseif(DEFINED ENV{DTC_OVERLAY_FILE})
set(DTC_OVERLAY_FILE $ENV{DTC_OVERLAY_FILE})
cmake: add app boards subdir as search location for board overlay files Putting overlay files in the test/sample root clutters the file system. Allow them to be in the boards subdirectory alongside board.conf files. Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
2019-09-24 14:16:27 +02:00
elseif(EXISTS ${APPLICATION_SOURCE_DIR}/boards/${BOARD}.overlay)
set(DTC_OVERLAY_FILE ${APPLICATION_SOURCE_DIR}/boards/${BOARD}.overlay)
cmake: dts: Allow multiple overlay files This patch changes the manner in which we collect DTS overlay files so that they comply with the same approach taken for configuration fragment files (.conf). Additionally it also documents the usage of those files in the Application Developer Guide. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-31 18:00:49 +01:00
elseif(EXISTS ${APPLICATION_SOURCE_DIR}/${BOARD}.overlay)
set(DTC_OVERLAY_FILE ${APPLICATION_SOURCE_DIR}/${BOARD}.overlay)
build: dts: also look for application specific dts overlay Not all DTS changes are board specific and we should support overlays that can be used with multiple boards. For example with a sensor, for example: Use this overlay for a sensor: &arduino_i2c { bme280@76 { compatible = "bosch,bme280"; reg = <0x76>; label = "BME280"; }; }; This will work with any board that has &arduino_i2c defined, but should also work if you specify the instance directly (&i2c0 or &i2c1). Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-15 13:21:13 +02:00
elseif(EXISTS ${APPLICATION_SOURCE_DIR}/app.overlay)
set(DTC_OVERLAY_FILE ${APPLICATION_SOURCE_DIR}/app.overlay)
cmake: dts: Allow multiple overlay files This patch changes the manner in which we collect DTS overlay files so that they comply with the same approach taken for configuration fragment files (.conf). Additionally it also documents the usage of those files in the Application Developer Guide. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-31 18:00:49 +01:00
endif()
set(DTC_OVERLAY_FILE ${DTC_OVERLAY_FILE} CACHE STRING "If desired, you can \
build the application using the DT configuration settings specified in an \
alternate .overlay file using this parameter. These settings will override the \
settings in the board's .dts file. Multiple files may be listed, e.g. \
DTC_OVERLAY_FILE=\"dts1.overlay dts2.overlay\"")
toolchain: improved toolchain abstraction for compilers and linker First abstraction completed for the toolchains: - gcc - clang Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-08-18 14:47:53 +02:00
# Populate USER_CACHE_DIR with a directory that user applications may
# write cache files to.
if(NOT DEFINED USER_CACHE_DIR)
find_appropriate_cache_directory(USER_CACHE_DIR)
endif()
message(STATUS "Cache files will be written to: ${USER_CACHE_DIR}")
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
# Prevent CMake from testing the toolchain
set(CMAKE_C_COMPILER_FORCED 1)
set(CMAKE_CXX_COMPILER_FORCED 1)
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
include(${ZEPHYR_BASE}/cmake/host-tools.cmake)
cmake: Split toolchain configuration into pre-and post-DT Split up the toolchain configuration into two phases, generic and target. The 'generic' phase configures the toolchain just enough to be able to preprocess DT files. The 'target' phase completes the configuration with target-specific configuration. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-12-13 16:32:07 +01:00
cmake: allow boards to have extra cmake parametes This commit allows boards to have custom cmake parameters that are loaded before device tree is processed. Signed-off-by: Andrei Gansari <andrei.gansari@nxp.com>
2019-11-20 10:36:13 +01:00
# Include board specific device-tree flags before parsing.
include(${BOARD_DIR}/pre_dt_board.cmake OPTIONAL)
cmake: Split toolchain configuration into pre-and post-DT Split up the toolchain configuration into two phases, generic and target. The 'generic' phase configures the toolchain just enough to be able to preprocess DT files. The 'target' phase completes the configuration with target-specific configuration. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-12-13 16:32:07 +01:00
# DTS should be close to kconfig because CONFIG_ variables from
# kconfig and dts should be available at the same time.
#
# The DT system uses a C preprocessor for it's code generation needs.
# This creates an awkward chicken-and-egg problem, because we don't
# always know exactly which toolchain the user needs until we know
# more about the target, e.g. after DT and Kconfig.
#
# To resolve this we find "some" C toolchain, configure it generically
# with the minimal amount of configuration needed to have it
# preprocess DT sources, and then, after we have finished processing
# both DT and Kconfig we complete the target-specific configuration,
# and possibly change the toolchain.
include(${ZEPHYR_BASE}/cmake/generic_toolchain.cmake)
cmake: Run dts before kconfig Based on work from Sebastian Bøe and updated to current tree. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no> Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-01-18 16:47:05 +01:00
include(${ZEPHYR_BASE}/cmake/dts.cmake)
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
include(${ZEPHYR_BASE}/cmake/kconfig.cmake)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
set(SOC_NAME ${CONFIG_SOC})
cmake: Move SOC_* var defines to cmake/app/boilerplate.cmake We need access to SOC_PATH in dts.cmake so we need to move the definitions of SOC_NAME, SOC_SERIES, SOC_FAMILY, and SOC_PATH out of the toplevel CMakeLists.txt and into cmake/app/boilerplate.cmake. We place them before we include cmake/dts.cmake so they will be available to use in it. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2018-02-22 16:25:03 +01:00
set(SOC_SERIES ${CONFIG_SOC_SERIES})
set(SOC_FAMILY ${CONFIG_SOC_FAMILY})
if("${SOC_SERIES}" STREQUAL "")
set(SOC_PATH ${SOC_NAME})
else()
set(SOC_PATH ${SOC_FAMILY}/${SOC_SERIES})
endif()
cmake: kconfig: support for multiple SOC_ROOT This commit introduces support for multiple SOC_ROOT. This means that additional SOC_ROOTs specified using -DSOC_ROOT as argument to CMake will be forming a list together with ${ZEPHYR_BASE}. This allows for greater flexibility, as developers can now specify multiple out-of-tree SoCs and not worry about the SoC used for the board they compile for. Also it avoid code, such as: if(BOARD STREQUAL my_board_using_out_of_tree_soc) set(SOC_ROOT some/out/of/tree/soc/path) endif() in application CMakeLists.txt. Finally, allowing multiple SOC_ROOTs prepares for specifying SOC_ROOTs in Zephyr modules. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-07-06 12:53:39 +02:00
# Use SOC to search for a 'CMakeLists.txt' file.
# e.g. zephyr/soc/xtense/intel_apl_adsp/CMakeLists.txt.
foreach(root ${SOC_ROOT})
if(EXISTS ${root}/soc/${ARCH}/${SOC_PATH})
set(SOC_DIR ${root}/soc)
break()
endif()
endforeach()
if(NOT SOC_DIR)
message(FATAL_ERROR "Could not find SOC=${SOC_NAME} for BOARD=${BOARD}, \
please check your installation. SOC roots searched: \n\
${SOC_ROOT}")
endif()
cmake: Split toolchain configuration into pre-and post-DT Split up the toolchain configuration into two phases, generic and target. The 'generic' phase configures the toolchain just enough to be able to preprocess DT files. The 'target' phase completes the configuration with target-specific configuration. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-12-13 16:32:07 +01:00
include(${ZEPHYR_BASE}/cmake/target_toolchain.cmake)
cmake: Move the invocation of 'project' earlier The CMake documentation for 'project' states "Call the project() command near the top of the top-level CMakeLists.txt". Meaning, it should be run as early as possible. An obscure internal error was observed when 'project' was located in zephyr/CMakeLists.txt and was observed to be fixed after moving 'project' earlier, hence this patch that moves it earlier. Invoking project depends on knowing information about the toolchain so it is placed after target_toolchain.cmake. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-09-27 14:05:53 +02:00
project(Zephyr-Kernel VERSION ${PROJECT_VERSION})
enable_language(C CXX ASM)
toolchain: improved toolchain abstraction for compilers and linker First abstraction completed for the toolchains: - gcc - clang Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2020-08-18 14:47:53 +02:00
# The setup / configuration of the toolchain itself and the configuration of
# supported compilation flags are now split, as this allows to use the toolchain
# for generic purposes, for example DTS, and then test the toolchain for
# supported flags at stage two.
# Testing the toolchain flags requires the enable_language() to have been called in CMake.
include(${ZEPHYR_BASE}/cmake/target_toolchain_flags.cmake)
cmake: Move the invocation of 'project' earlier The CMake documentation for 'project' states "Call the project() command near the top of the top-level CMakeLists.txt". Meaning, it should be run as early as possible. An obscure internal error was observed when 'project' was located in zephyr/CMakeLists.txt and was observed to be fixed after moving 'project' earlier, hence this patch that moves it earlier. Invoking project depends on knowing information about the toolchain so it is placed after target_toolchain.cmake. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-09-27 14:05:53 +02:00
# 'project' sets PROJECT_BINARY_DIR to ${CMAKE_CURRENT_BINARY_DIR},
# but for legacy reasons we need it to be set to
# ${CMAKE_CURRENT_BINARY_DIR}/zephyr
set(PROJECT_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}/zephyr)
set(PROJECT_SOURCE_DIR ${ZEPHYR_BASE})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(KERNEL_NAME ${CONFIG_KERNEL_BIN_NAME})
set(KERNEL_ELF_NAME ${KERNEL_NAME}.elf)
set(KERNEL_BIN_NAME ${KERNEL_NAME}.bin)
set(KERNEL_HEX_NAME ${KERNEL_NAME}.hex)
set(KERNEL_MAP_NAME ${KERNEL_NAME}.map)
set(KERNEL_LST_NAME ${KERNEL_NAME}.lst)
set(KERNEL_S19_NAME ${KERNEL_NAME}.s19)
native: build zephyr.exe for posix arch To indicate the generated binary is executable on the host, add .exe extension to the generated ELF file. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-11-23 13:54:26 +01:00
set(KERNEL_EXE_NAME ${KERNEL_NAME}.exe)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
set(KERNEL_STAT_NAME ${KERNEL_NAME}.stat)
set(KERNEL_STRIP_NAME ${KERNEL_NAME}.strip)
include(${BOARD_DIR}/board.cmake OPTIONAL)
net: qemu: Allow SLIP or normal ethernet connectivity Introduce new Kconfig option for selecting either slip or ethernet connectivity to host. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2018-10-16 13:27:21 +02:00
# If we are using a suitable ethernet driver inside qemu, then these options
# must be set, otherwise a zephyr instance cannot receive any network packets.
# The Qemu supported ethernet driver should define CONFIG_ETH_NIC_MODEL
# string that tells what nic model Qemu should use.
if(CONFIG_QEMU_TARGET)
net: qemu: Adding support for User Networking Added support for Qemu User Networking and tested with qemu_x86 model. The support is kept simple assuming that the TAP interface will always be preferred for more sophisticated / practical use cases. QEMU User Networking is implemented using "slirp", which provides a full TCP/IP stack within QEMU and uses that stack to implement a virtual NAT'd network. As this support is built into QEMU, it can be used with any model and requires no admin privileges on the host machine, unlike TAP. Added documentation to facilitate the user. Signed-off-by: Bilal Wasim <bilalwasim676@gmail.com>
2020-05-06 01:56:52 +02:00
if ((CONFIG_NET_QEMU_ETHERNET OR CONFIG_NET_QEMU_USER) AND NOT CONFIG_ETH_NIC_MODEL)
message(FATAL_ERROR "
No Qemu ethernet driver configured!
Enable Qemu supported ethernet driver like e1000 at drivers/ethernet"
)
elseif(CONFIG_NET_QEMU_ETHERNET)
cmake: qemu: Allow user to add parameters to Ethernet TAP User can now add extra Ethernet TAP parameters when starting QEMU. This is useful if we want to set for example the MAC address of the network interface. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2020-05-08 14:25:03 +02:00
if(CONFIG_ETH_QEMU_EXTRA_ARGS)
set(NET_QEMU_ETH_EXTRA_ARGS ",${CONFIG_ETH_QEMU_EXTRA_ARGS}")
endif()
net: qemu: Adding support for User Networking Added support for Qemu User Networking and tested with qemu_x86 model. The support is kept simple assuming that the TAP interface will always be preferred for more sophisticated / practical use cases. QEMU User Networking is implemented using "slirp", which provides a full TCP/IP stack within QEMU and uses that stack to implement a virtual NAT'd network. As this support is built into QEMU, it can be used with any model and requires no admin privileges on the host machine, unlike TAP. Added documentation to facilitate the user. Signed-off-by: Bilal Wasim <bilalwasim676@gmail.com>
2020-05-06 01:56:52 +02:00
list(APPEND QEMU_FLAGS_${ARCH}
cmake: qemu: Allow user to add parameters to Ethernet TAP User can now add extra Ethernet TAP parameters when starting QEMU. This is useful if we want to set for example the MAC address of the network interface. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2020-05-08 14:25:03 +02:00
-nic tap,model=${CONFIG_ETH_NIC_MODEL},script=no,downscript=no,ifname=${CONFIG_ETH_QEMU_IFACE_NAME}${NET_QEMU_ETH_EXTRA_ARGS}
net: qemu: Adding support for User Networking Added support for Qemu User Networking and tested with qemu_x86 model. The support is kept simple assuming that the TAP interface will always be preferred for more sophisticated / practical use cases. QEMU User Networking is implemented using "slirp", which provides a full TCP/IP stack within QEMU and uses that stack to implement a virtual NAT'd network. As this support is built into QEMU, it can be used with any model and requires no admin privileges on the host machine, unlike TAP. Added documentation to facilitate the user. Signed-off-by: Bilal Wasim <bilalwasim676@gmail.com>
2020-05-06 01:56:52 +02:00
)
elseif(CONFIG_NET_QEMU_USER)
list(APPEND QEMU_FLAGS_${ARCH}
-nic user,model=${CONFIG_ETH_NIC_MODEL},${CONFIG_NET_QEMU_USER_EXTRA_ARGS}
)
net: qemu: Allow SLIP or normal ethernet connectivity Introduce new Kconfig option for selecting either slip or ethernet connectivity to host. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2018-10-16 13:27:21 +02:00
else()
list(APPEND QEMU_FLAGS_${ARCH}
-net none
cmake: Whitespace and commentary fixes Cosmetics, no functional change expected. Fixed leading space alignment. Replaced tabs with spaces. Emulation error message output is now aligned. To locate tabs in cmake, the following bash is useful: grep -PRil "\t" * | grep -i cmake | grep -v ^sanity Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 10:40:57 +01:00
)
net: qemu: Allow SLIP or normal ethernet connectivity Introduce new Kconfig option for selecting either slip or ethernet connectivity to host. Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2018-10-16 13:27:21 +02:00
endif()
endif()
cmake: app mem partion flexibility This commit allows a more dynamic approach for specifying that a zephyr library must be placed in a dedicated app memomory partition. This is still done by defining the partition in code using K_APPMEM_PARTITION_DEFINE, but now the zephyr library can be added to the generation of partition table using zephyr_library_app_memory instead of modifying the overall zephyr/CMakeLists.txt file. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2019-11-04 14:30:24 +01:00
# General purpose Zephyr target.
# This target can be used for custom zephyr settings that needs to be used elsewhere in the build system
#
# Currently used properties:
# - COMPILES_OPTIONS: Used by application memory partition feature
build: update stale comment in boilerplate.cmake The zephyr_property_target use cases have grown. Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
2020-08-19 23:09:45 +02:00
# - ${TARGET}_DEPENDENCIES: additional dependencies for targets that need them
# like flash (FLASH_DEPENDENCIES), debug (DEBUG_DEPENDENCIES), etc.
cmake: app mem partion flexibility This commit allows a more dynamic approach for specifying that a zephyr library must be placed in a dedicated app memomory partition. This is still done by defining the partition in code using K_APPMEM_PARTITION_DEFINE, but now the zephyr library can be added to the generation of partition table using zephyr_library_app_memory instead of modifying the overall zephyr/CMakeLists.txt file. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
2019-11-04 14:30:24 +01:00
add_custom_target(zephyr_property_target)
cmake: boilerplate: Move app-library to be with its documentation Move documentation and declaration to be in the same place. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-11-26 23:49:53 +01:00
# "app" is a CMake library containing all the application code and is
# modified by the entry point ${APPLICATION_SOURCE_DIR}/CMakeLists.txt
# that was specified when cmake was called.
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
zephyr_library_named(app)
cmake: Move libapp.a into it's own directory Move libapp.a into it's own directory. This would make it's placement consistent with how zephyr.elf is placed. E.g. it might now look like: ls b/* b/build.ninja b/CMakeCache.txt b/cmake_install.cmake b/rules.ninja b/app: libapp.a b/CMakeFiles: 3.12.0 cmake.check_cache CMakeOutput.log TargetDirectories.txt app.dir CMakeError.log CMakeTmp b/zephyr: arch kernel subsys boards lib tests cmake liboffsets.a zephyr.bin CMakeFiles libzephyr.a zephyr.elf cmake_install.cmake linker.cmd zephyr.hex ext linker_pass_final.cmd zephyr.map include linker_pass_final.cmd.dep zephyr_prebuilt.elf isrList.bin misc zephyr.stat Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-08-06 17:29:16 +02:00
set_property(TARGET app PROPERTY ARCHIVE_OUTPUT_DIRECTORY app)
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
add_subdirectory(${ZEPHYR_BASE} ${__build_dir})
Introduce cmake-based rewrite of KBuild Introducing CMake is an important step in a larger effort to make Zephyr easy to use for application developers working on different platforms with different development environment needs. Simplified, this change retains Kconfig as-is, and replaces all Makefiles with CMakeLists.txt. The DSL-like Make language that KBuild offers is replaced by a set of CMake extentions. These extentions have either provided simple one-to-one translations of KBuild features or introduced new concepts that replace KBuild concepts. This is a breaking change for existing test infrastructure and build scripts that are maintained out-of-tree. But for FW itself, no porting should be necessary. For users that just want to continue their work with minimal disruption the following should suffice: Install CMake 3.8.2+ Port any out-of-tree Makefiles to CMake. Learn the absolute minimum about the new command line interface: $ cd samples/hello_world $ mkdir build && cd build $ cmake -DBOARD=nrf52_pca10040 .. $ cd build $ make PR: zephyrproject-rtos#4692 docs: http://docs.zephyrproject.org/getting_started/getting_started.html Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-10-27 15:43:34 +02:00
cmake: Introduce Zephyr interface libraries Introduce Zephyr interface libraries to fix #5351. From the documentation: A Zephyr interface library is a thin wrapper over a CMake INTERFACE library. The most important responsibility of this abstraction is to ensure that when a user KConfig-enables a library then the header files of this library will be accessible to the 'app' library. This is done because when a user uses Kconfig to enable a library he expects to be able to include it's header files and call it's functions out-of-the box. A Zephyr interface library should be used when there exists some build information (include directories, defines, compiler flags, etc.) that should be applied to a set of Zephyr libraries and 'app' might be one of these libraries. Zephyr libraries must explicitly call zephyr_library_link_libraries(<interface_library>) to use this build information. 'app' is treated as a special case for usability reasons; a Kconfig option (CONFIG_APP_LINK_WITH_<interface_library>) should exist for each interface_library and will determine if 'app' links with the interface_library. This API has a constructor like the zephyr_library API has, but it Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-27 16:08:06 +01:00
# Link 'app' with the Zephyr interface libraries.
#
# NB: This must be done in boilerplate.cmake because 'app' can only be
# modified in the CMakeLists.txt file that created it. And it must be
cmake: Use path-corrected version of ZEPHYR_BASE Instead of accessing the environment variable ZEPHYR_BASE every time we require accessing the source code root, use an intermediate variable that has OS path separators correctly set to '/' to avoid issues on Windows. Note: This removes the ZEPHYR_SOURCE_DIR CMake variable. External applications using that will need to change to use the new ZEPHYR_BASE variable. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2018-01-11 15:46:44 +01:00
# done after 'add_subdirectory(${ZEPHYR_BASE} ${__build_dir})'
cmake: Introduce Zephyr interface libraries Introduce Zephyr interface libraries to fix #5351. From the documentation: A Zephyr interface library is a thin wrapper over a CMake INTERFACE library. The most important responsibility of this abstraction is to ensure that when a user KConfig-enables a library then the header files of this library will be accessible to the 'app' library. This is done because when a user uses Kconfig to enable a library he expects to be able to include it's header files and call it's functions out-of-the box. A Zephyr interface library should be used when there exists some build information (include directories, defines, compiler flags, etc.) that should be applied to a set of Zephyr libraries and 'app' might be one of these libraries. Zephyr libraries must explicitly call zephyr_library_link_libraries(<interface_library>) to use this build information. 'app' is treated as a special case for usability reasons; a Kconfig option (CONFIG_APP_LINK_WITH_<interface_library>) should exist for each interface_library and will determine if 'app' links with the interface_library. This API has a constructor like the zephyr_library API has, but it Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-27 16:08:06 +01:00
# because interface libraries are defined while processing that
# subdirectory.
get_property(ZEPHYR_INTERFACE_LIBS_PROPERTY GLOBAL PROPERTY ZEPHYR_INTERFACE_LIBS)
foreach(boilerplate_lib ${ZEPHYR_INTERFACE_LIBS_PROPERTY})
# Linking 'app' with 'boilerplate_lib' causes 'app' to inherit the INTERFACE
# properties of 'boilerplate_lib'. The most common property is 'include
# directories', but it is also possible to have defines and compiler
# flags in the interface of a library.
#
string(TOUPPER ${boilerplate_lib} boilerplate_lib_upper_case) # Support lowercase lib names
target_link_libraries_ifdef(
CONFIG_APP_LINK_WITH_${boilerplate_lib_upper_case}
app
cmake: Refactor usage of target_link_libraries on Zephyr libraries CMake has several prototypes/signatures for the function 'target_link_libraries'. This commit migrates the usage of 'target_link_libraries' on Zephyr CMake libraries from the old 'plain' signature to the new '<PRIVATE|PUBLIC|INTERFACE>' signature. For technical reasons the two signatures can not be mixed. Each library must exclusively use either the old or new signature. The 'old' plain signature is equivalent to using the PUBLIC signature. Migrating to use 'PUBLIC' is therefore expected to be a safe change. After the migration it will be possible to use the PRIVATE and INTERFACE signatures on Zephyr CMake libraries. This is useful for instance to fix issue 8438. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-06-22 14:35:44 +02:00
PUBLIC
cmake: Introduce Zephyr interface libraries Introduce Zephyr interface libraries to fix #5351. From the documentation: A Zephyr interface library is a thin wrapper over a CMake INTERFACE library. The most important responsibility of this abstraction is to ensure that when a user KConfig-enables a library then the header files of this library will be accessible to the 'app' library. This is done because when a user uses Kconfig to enable a library he expects to be able to include it's header files and call it's functions out-of-the box. A Zephyr interface library should be used when there exists some build information (include directories, defines, compiler flags, etc.) that should be applied to a set of Zephyr libraries and 'app' might be one of these libraries. Zephyr libraries must explicitly call zephyr_library_link_libraries(<interface_library>) to use this build information. 'app' is treated as a special case for usability reasons; a Kconfig option (CONFIG_APP_LINK_WITH_<interface_library>) should exist for each interface_library and will determine if 'app' links with the interface_library. This API has a constructor like the zephyr_library API has, but it Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-27 16:08:06 +01:00
${boilerplate_lib}
)
endforeach()
cmake: Eclipse CDT4 generator amendment 1. The generator handles just the COMPILE_DEFINITIONS. (See: __ZEPHYR_SUPERVISOR__) For the defines in INTERFACE_COMPILE_DEFINITIONS a special handling is necessary. Solution: The amendment function generates a macro header file ${CMAKE_BINARY_DIR}/zephyr/include/generated/cmake_intdef.h based on INTERFACE_COMPILE_DEFINITIONS and appends the defines from the file to CMAKE_EXTRA_GENERATOR_C_SYSTEM_DEFINED_MACROS. 2. Eclipse CDT4 indexer has problems with CMake 'Eclipse CDT4 - x' generator projects that use mixed C/C++. The Eclipse CDT4 indexer is showing a lot of unresolved symbol errors, when the project was created with CMake generator and the code is a mix of C and C++. The root cause of the problem is the g++ built-in __cplusplus macro, that is passed by CMake generator in the '.cproject' file. The defines in '.cproject' are always the same for C and C++. In mixed C/C++ projects, the header files often contain the following lines to let C++ code call the C functions: #ifdef __cplusplus extern "C" { #endif < header content > #ifdef __cplusplus } #endif Whenever the Eclipse CDT4 indexer compiles the code for code analysis, it has the macro __cplusplus set, independent of whether standard C or C++ source files are compiled. The 'extern "C"' confuses the standard C compilation and the indexer is messed up. Solution: The amendment function deletes the __cplusplus entry from CMAKE_EXTRA_GENERATOR_CXX_SYSTEM_DEFINED_MACROS. 3. The amendment function appends the defines from ${CMAKE_BINARY_DIR}/zephyr/include/generated/autoconf.h to CMAKE_EXTRA_GENERATOR_C_SYSTEM_DEFINED_MACROS. Signed-off-by: Istvan Bisz <istvan.bisz@t-online.hu>
2018-09-17 15:02:54 +02:00
if("${CMAKE_EXTRA_GENERATOR}" STREQUAL "Eclipse CDT4")
# Call the amendment function before .project and .cproject generation
# C and CXX includes, defines in .cproject without __cplusplus
# with project includes and defines
include(${ZEPHYR_BASE}/cmake/ide/eclipse_cdt4_generator_amendment.cmake)
eclipse_cdt4_generator_amendment(1)
endif()
Reference in a new issue Copy permalink