patrick/zephyr
1
0
Fork 0
Code Issues Pull requests Actions 8 Packages Projects Releases Wiki Activity
zephyr/CMakeLists.txt

1504 lines
51 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
cmake: Move root CMakeLists.txt's comment-header to top Inform user early on that ./CMakeLists.txt is not the top-level file. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2018-12-19 16:27:55 +01:00
# *DOCUMENTATION*
#
# Note that this is *NOT* the top-level CMakeLists.txt. That's in the
# application. See the Application Development Primer documentation
# for details.
#
# To see a list of typical targets execute "make usage"
# More info can be located in ./README.rst
# Comments in this file are targeted only to the developer, do not
# expect to learn how to build the kernel reading this file.
cmake: Improve user error feedback when -H$ZEPHYR_BASE is specified Users are sometimes mistakenly invoking cmake with $ZEPHYR_BASE set as the source directory. This user-error can occur if the user believes that the toplevel CMakeLists.txt file is at the root of the repo, or if the user uses the wrong path when invoking cmake. The error given when this user-error occurs is cryptic and undefined, so we replace it with what should be an easy-to-understand error message. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-06-04 11:47:45 +02:00
if(NOT DEFINED ZEPHYR_BINARY_DIR)
docs: fix misspelling across the tree Found a few annoying typos and figured I better run script and fix anything it can find, here are the results... Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-18 20:45:40 +02:00
message(FATAL_ERROR "A user error has occurred.
cmake: Improve user error feedback when -H$ZEPHYR_BASE is specified Users are sometimes mistakenly invoking cmake with $ZEPHYR_BASE set as the source directory. This user-error can occur if the user believes that the toplevel CMakeLists.txt file is at the root of the repo, or if the user uses the wrong path when invoking cmake. The error given when this user-error occurs is cryptic and undefined, so we replace it with what should be an easy-to-understand error message. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-06-04 11:47:45 +02:00
cmake was invoked with '${CMAKE_CURRENT_LIST_DIR}' specified as the source directory,
but it must be invoked with an application source directory,
such as '${CMAKE_CURRENT_LIST_DIR}/samples/hello_world'.
Debug variables:
CMAKE_CACHEFILE_DIR: ${CMAKE_CACHEFILE_DIR}
")
endif()
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
# See https://gitlab.kitware.com/cmake/cmake/issues/16228
# and https://cmake.org/pipermail/cmake/2019-May/thread.html#69496
if(NOT ZEPHYR_BASE STREQUAL CMAKE_CURRENT_SOURCE_DIR)
message(WARNING "ZEPHYR_BASE doesn't match CMAKE_CURRENT_SOURCE_DIR
ZEPHYR_BASE = ${ZEPHYR_BASE}
PWD = $ENV{PWD}
CMAKE_CURRENT_SOURCE_DIR = ${CMAKE_CURRENT_SOURCE_DIR}
You may be using a mix of symbolic links and real paths which causes \
subtle and hard to debug CMake issues.")
endif()
# For Zephyr more specifically this breaks (at least)
# -fmacro-prefix-map=${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
project(Zephyr-Kernel VERSION ${PROJECT_VERSION})
enable_language(C CXX ASM)
# Verify that the toolchain can compile a dummy file, if it is not we
docs: fix misspelling across the tree Found a few annoying typos and figured I better run script and fix anything it can find, here are the results... Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-06-18 20:45:40 +02:00
# won't be able to test for compatibility with certain C flags.
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
check_c_compiler_flag("" toolchain_is_ok)
assert(toolchain_is_ok "The toolchain is unable to build a dummy C file. See CMakeError.log.")
cmake: stop destroying intermediate link maps like zephyr_prebuilt.map The different linker steps are all hardcoded to the output filename "zephyr.map" and only the last one survives. Un-harcode. This removes some confusion when trying to follow who builds what/when/how and it stops destroying intermediate linking information useful when tracing/debugging new features or issues in the build. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-14 01:15:44 +02:00
# In some cases the "final" things are not used at all and "_prebuilt"
# is the last station. See "logical_target_for_zephyr_elf" below for
# details.
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(CMAKE_EXECUTABLE_SUFFIX .elf)
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
set(ZEPHYR_PREBUILT_EXECUTABLE zephyr_prebuilt)
cmake: Rename kernel_elf to zephyr_final * KERNEL_ELF was easily confused with KERNEL_ELF_NAME and KERNEL_NAME. * kernel_elf as the name of the binary indicates it somehow only contains the kernel, which is not correct. Rename to zephyr_final as this is the reality: Zephyr elf has been linked again (a number of times) due to generated kernel files. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 15:20:20 +02:00
set(ZEPHYR_FINAL_EXECUTABLE zephyr_final)
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: change construct_add_custom_command_for_linker_pass into macro Change construct_add_custom_command_for_linker_pass from function into macro. The purpose of the function was to set the output variable to a string that would be fed to add_custom_command. This meant all use required a two-step procedure and an intermediate variable (custom_command). The environmental leakage from a macro in this case is small, so let's just simplify to a macro and avoid the two-step. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 16:57:37 +02:00
# Set some phony targets to collect dependencies
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
set(OFFSETS_H_TARGET offsets_h)
set(SYSCALL_MACROS_H_TARGET syscall_macros_h_target)
set(SYSCALL_LIST_H_TARGET syscall_list_h_target)
set(DRIVER_VALIDATION_H_TARGET driver_validation_h_target)
set(KOBJ_TYPES_H_TARGET kobj_types_h_target)
set(LINKER_SCRIPT_TARGET linker_script_target)
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
define_property(GLOBAL PROPERTY PROPERTY_OUTPUT_FORMAT BRIEF_DOCS " " FULL_DOCS " ")
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_property( GLOBAL PROPERTY PROPERTY_OUTPUT_FORMAT elf32-little${ARCH}) # BFD format
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
# "zephyr_interface" is a source-less library that encapsulates all the global
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
# compiler options needed by all source files. All zephyr libraries,
# including the library named "zephyr" link with this library to
# obtain these flags.
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
# https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#interface-libraries
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
add_library(zephyr_interface INTERFACE)
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" is a catch-all CMake library for source files that can be
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
# built purely with the include paths, defines, and other compiler
# flags that come with zephyr_interface.
zephyr_library_named(zephyr)
zephyr_include_directories(
kernel/include
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
${ARCH_DIR}/${ARCH}/include
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
include
include/drivers
${PROJECT_BINARY_DIR}/include/generated
${USERINCLUDE}
${STDINCLUDE}
)
cmake: Don't use non-existing include paths Don't add non-existing include directories, it creates noise and even warnings in some tooling, like Eclipse. This fixes #12696 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-25 10:14:13 +01:00
# Don't add non-existing include directories, it creates noise and
# warnings in some tooling
foreach(optional_include_dir
${SOC_DIR}/${ARCH}/${SOC_PATH}
${SOC_DIR}/${ARCH}/${SOC_PATH}/include
${SOC_DIR}/${ARCH}/${SOC_FAMILY}/include
)
if(EXISTS ${optional_include_dir})
zephyr_include_directories(${optional_include_dir})
endif()
endforeach()
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_compile_definitions(
KERNEL
__ZEPHYR__=1
coverage: build with -O0 to get more information per the gcov man page: You should compile your code without optimization if you plan to use gcov because the optimization, by combining some lines of code into one function, may not give you as much information . Fixes #5548 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-01-03 18:26:19 +01:00
)
cmake: Toolchain abstraction: security Introduce the first of the toolchain_cc-family of macros: toolchain_cc_security_fortify and toolchain_cc_security_canaries. No functional change expected. Fortify source is not supported by Clang, but this commit retains current behavior. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-10 12:07:51 +01:00
# @Intent: Set compiler flags to enable buffer overflow checks in libc functions
# @config in CONFIG_NO_OPTIMIZATIONS optional : Optimizations may affect security
toolchain_cc_security_fortify()
# @Intent: Set compiler flags to detect general stack overflows across all functions
if(CONFIG_STACK_CANARIES)
toolchain_cc_security_canaries()
coverage: build with -O0 to get more information per the gcov man page: You should compile your code without optimization if you plan to use gcov because the optimization, by combining some lines of code into one function, may not give you as much information . Fixes #5548 Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-01-03 18:26:19 +01:00
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
build: use git version and hash for boot banner This uses the version and hash (git describe) and replaces the timestamp currently used in the boot banner. This works much better than using timestamps. It lets us point to the exact commit being used to run a certain application or test. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-04-10 04:53:26 +02:00
if(BUILD_VERSION)
zephyr_compile_definitions(
BUILD_VERSION=${BUILD_VERSION}
)
endif()
cmake: Toolchain abstraction: optimizations Introduce toolchain_cc_optimize_for_* family of macros. Each macro represents a general optimization class. Each macro is then responsible for setting an output variable to that class-of-optimization's flag. The names of these output variables are decided from the root CMakeLists.txt. No functional change expected. Clang's optimization flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-30 10:12:30 +01:00
# @Intent: Obtain compiler optimizations flags and store in variables
# @details:
# Kconfig.zephyr "Optimization level" is a kconfig choice, ensuring
# only *one* of CONFIG_{NO,DEBUG,SPEED,SIZE}_OPTIMIZATIONS is set.
# Refer to Kconfig.zephyr for selection logic and description of these choices.
# toolchain_cc_optimize_*() macros must provide the mapping from these kconfigs
# to compiler flags. Each macro will store the flags in a CMake variable, whose
# name is passed as argument (somewhat like by reference).
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: Toolchain abstraction: optimizations Introduce toolchain_cc_optimize_for_* family of macros. Each macro represents a general optimization class. Each macro is then responsible for setting an output variable to that class-of-optimization's flag. The names of these output variables are decided from the root CMakeLists.txt. No functional change expected. Clang's optimization flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-30 10:12:30 +01:00
# If the user wants to tweak the optimizations, there are two ways:
# 1) Using EXTRA_CFLAGS which is applied regardless of kconfig choice, or
# 2) Rely on override support being implemented by your toolchain_cc_optimize_*()
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: Toolchain abstraction: optimizations Introduce toolchain_cc_optimize_for_* family of macros. Each macro represents a general optimization class. Each macro is then responsible for setting an output variable to that class-of-optimization's flag. The names of these output variables are decided from the root CMakeLists.txt. No functional change expected. Clang's optimization flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-30 10:12:30 +01:00
toolchain_cc_optimize_for_no_optimizations_flag(OPTIMIZE_FOR_NO_OPTIMIZATIONS_FLAG)
toolchain_cc_optimize_for_debug_flag(OPTIMIZE_FOR_DEBUG_FLAG)
toolchain_cc_optimize_for_speed_flag(OPTIMIZE_FOR_SPEED_FLAG)
toolchain_cc_optimize_for_size_flag(OPTIMIZE_FOR_SIZE_FLAG)
kconfig: Change how optimization level is set This patch does several things, most notably it changes the semantics of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined "debug mode" that enables printf's, -Og, etc. but now the user may choose to be in "debug mode" while using a different optimization level than -Og. Tp support this a new config is defined to enable -Og; CONFIG_DEBUG_OPTIMIZATIONS. Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user to explicitly request optimizing for size instead of relying on defaulting to it. The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in a Kconfig choice to ensure that at most one can be enabled at a time. Finally, selected users of CONFIG_DEBUG have been ported to use one of the optimizations configs when it was clear from usage that the intention was to behave differently when using a different optimization level and not when in "debug mode". Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-24 10:40:32 +01:00
cmake: Toolchain abstraction: optimizations Introduce toolchain_cc_optimize_for_* family of macros. Each macro represents a general optimization class. Each macro is then responsible for setting an output variable to that class-of-optimization's flag. The names of these output variables are decided from the root CMakeLists.txt. No functional change expected. Clang's optimization flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-30 10:12:30 +01:00
# From kconfig choice, pick the actual OPTIMIZATION_FLAG to use.
# Kconfig choice ensures only one of these CONFIG_*_OPTIMIZATIONS is set.
build: Added CONFIG_NO_OPTIMIZATIONS Added a new config option which lowers the compiler optimizations to -O0 independently of other flags. CONFIG_COVERAGE uses it now instead of having its own choice in CMakeLists.txt Fixes #5720 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2018-01-22 15:35:54 +01:00
if(CONFIG_NO_OPTIMIZATIONS)
kconfig: Change how optimization level is set This patch does several things, most notably it changes the semantics of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined "debug mode" that enables printf's, -Og, etc. but now the user may choose to be in "debug mode" while using a different optimization level than -Og. Tp support this a new config is defined to enable -Og; CONFIG_DEBUG_OPTIMIZATIONS. Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user to explicitly request optimizing for size instead of relying on defaulting to it. The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in a Kconfig choice to ensure that at most one can be enabled at a time. Finally, selected users of CONFIG_DEBUG have been ported to use one of the optimizations configs when it was clear from usage that the intention was to behave differently when using a different optimization level and not when in "debug mode". Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-24 10:40:32 +01:00
set(OPTIMIZATION_FLAG ${OPTIMIZE_FOR_NO_OPTIMIZATIONS_FLAG})
elseif(CONFIG_DEBUG_OPTIMIZATIONS)
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(OPTIMIZATION_FLAG ${OPTIMIZE_FOR_DEBUG_FLAG})
kconfig: add a compiler speed optimization Zephyr currently allows users to choose a compiler optimization between -O0, -Og and -Os, the default being the latter as it offers a good compromise between speed and flash usage. In cases the speed matters and/or the flash usage doesn't, optimizing for speed with -O2 is another alternative. For example in case of a simple application doing cryptographic signature validation with mbedtls, the flash size increase by about 15% compared to -Os, while it provides a 15% speed boost for a RSA signature and 30% speed boost for a ECC signature. This patches therefore adds a new option CONFIG_SPEED_OPTIMIZATIONS corresponding to the -O2 flag, but keep the default set to CONFIG_SIZE_OPTIMIZATIONS. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2018-06-16 23:40:04 +02:00
elseif(CONFIG_SPEED_OPTIMIZATIONS)
set(OPTIMIZATION_FLAG ${OPTIMIZE_FOR_SPEED_FLAG})
kconfig: Change how optimization level is set This patch does several things, most notably it changes the semantics of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined "debug mode" that enables printf's, -Og, etc. but now the user may choose to be in "debug mode" while using a different optimization level than -Og. Tp support this a new config is defined to enable -Og; CONFIG_DEBUG_OPTIMIZATIONS. Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user to explicitly request optimizing for size instead of relying on defaulting to it. The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in a Kconfig choice to ensure that at most one can be enabled at a time. Finally, selected users of CONFIG_DEBUG have been ported to use one of the optimizations configs when it was clear from usage that the intention was to behave differently when using a different optimization level and not when in "debug mode". Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-24 10:40:32 +01:00
elseif(CONFIG_SIZE_OPTIMIZATIONS)
cmake: Toolchain abstraction: optimizations Introduce toolchain_cc_optimize_for_* family of macros. Each macro represents a general optimization class. Each macro is then responsible for setting an output variable to that class-of-optimization's flag. The names of these output variables are decided from the root CMakeLists.txt. No functional change expected. Clang's optimization flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-30 10:12:30 +01:00
set(OPTIMIZATION_FLAG ${OPTIMIZE_FOR_SIZE_FLAG}) # Default in kconfig
kconfig: Change how optimization level is set This patch does several things, most notably it changes the semantics of CONFIG_DEBUG. CONFIG_DEBUG continues to behave as a vaguely defined "debug mode" that enables printf's, -Og, etc. but now the user may choose to be in "debug mode" while using a different optimization level than -Og. Tp support this a new config is defined to enable -Og; CONFIG_DEBUG_OPTIMIZATIONS. Additionally CONFIG_SIZE_OPTIMIZATIONS is introduced to allow the user to explicitly request optimizing for size instead of relying on defaulting to it. The three config's {NO,SIZE,DEBUG}_OPTIMIZATIONS are now organized in a Kconfig choice to ensure that at most one can be enabled at a time. Finally, selected users of CONFIG_DEBUG have been ported to use one of the optimizations configs when it was clear from usage that the intention was to behave differently when using a different optimization level and not when in "debug mode". Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-24 10:40:32 +01:00
else()
cmake: fix assert message about misc/Kconfig We have no Kconfig in misc/. Most options were moved to Kconfig.zephyr. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-01-19 01:15:19 +01:00
assert(0 "Unreachable code. Expected optimization level to have been chosen. See Kconfig.zephyr")
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
endif()
cmake: Toolchain abstraction: optimizations Introduce toolchain_cc_optimize_for_* family of macros. Each macro represents a general optimization class. Each macro is then responsible for setting an output variable to that class-of-optimization's flag. The names of these output variables are decided from the root CMakeLists.txt. No functional change expected. Clang's optimization flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-30 10:12:30 +01:00
# Apply the final optimization flag(s)
zephyr_compile_options(${OPTIMIZATION_FLAG})
cmake: Toolchain abstraction: C++ Introduce toolchain_cc_cpp_*-family of macros. Move the following into the toolchain_cc_cpp_* macros: * Common base set of flags * C++ standard version * RTTI * Exceptions These macros must be implemented by every compiler port. These macros set the respective flags, but leaves logic and control to the root CMakeLists.txt file. No functional change expected. Clang's C++ flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-02-18 23:54:30 +01:00
# @Intent: Obtain compiler specific flags related to C++ that are not influenced by kconfig
toolchain_cc_cpp_base_flags(CPP_BASE_FLAGS)
foreach(flag ${CPP_BASE_FLAGS})
zephyr_compile_options(
$<$<COMPILE_LANGUAGE:CXX>:${flag}>
)
endforeach()
# @Intent: Obtain compiler specific flags for compiling under different ISO standards of C++
toolchain_cc_cpp_dialect_std_98_flags(CPP_DIALECT_STD_98_FLAGS)
toolchain_cc_cpp_dialect_std_11_flags(CPP_DIALECT_STD_11_FLAGS)
toolchain_cc_cpp_dialect_std_14_flags(CPP_DIALECT_STD_14_FLAGS)
toolchain_cc_cpp_dialect_std_17_flags(CPP_DIALECT_STD_17_FLAGS)
toolchain_cc_cpp_dialect_std_2a_flags(CPP_DIALECT_STD_2A_FLAGS)
Build: Improve C++ support Can choose the C++ standard (C++98/11/14/17/2a) Can link with standard C++ library (libstdc++) Add support of C++ exceptions Add support of C++ RTTI Add C++ options to subsys/cpp/Kconfig Implements new and delete using k_malloc and k_free if CONFIG_HEAP_MEM_POOL_SIZE is defined Signed-off-by: Benoit Leforestier <benoit.leforestier@gmail.com>
2018-10-23 18:20:51 +02:00
c++: kconfig: Fix choice dependencies and use 'menuconfig' symbol - Make the 'C++ Standard' choice depend on CPLUSPLUS, so that it only shows up when C++ support is enabled. Also check that CPLUSPLUS is enabled before checking the standard in the top-level CMakeLists.txt, to avoid triggering an assert. - The 'C++ Options' menu now contains just CPLUSPLUS and its indented children. Remove one menu level by removing the menu and turning CPLUSPLUS into a 'menuconfig' symbol. Also change the prompt from "Enable C++ support for the application" to just "C++ support for the application", to make it consistent with e.g. "Logging". - Factor out the common CPLUSPLUS dependency with an 'if CPLUSPLUS'. - Order symbol properties more consistently with other Kconfig files, with the prompt at the top, etc. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-05-15 23:01:58 +02:00
if(CONFIG_CPLUSPLUS)
# From kconfig choice, pick a single dialect.
# Kconfig choice ensures only one of these CONFIG_STD_CPP* is set.
if(CONFIG_STD_CPP98)
set(STD_CPP_DIALECT_FLAGS ${CPP_DIALECT_STD_98_FLAGS})
elseif(CONFIG_STD_CPP11)
set(STD_CPP_DIALECT_FLAGS ${CPP_DIALECT_STD_11_FLAGS}) # Default in kconfig
elseif(CONFIG_STD_CPP14)
set(STD_CPP_DIALECT_FLAGS ${CPP_DIALECT_STD_14_FLAGS})
elseif(CONFIG_STD_CPP17)
set(STD_CPP_DIALECT_FLAGS ${CPP_DIALECT_STD_17_FLAGS})
elseif(CONFIG_STD_CPP2A)
set(STD_CPP_DIALECT_FLAGS ${CPP_DIALECT_STD_2A_FLAGS})
else()
assert(0 "Unreachable code. Expected C++ standard to have been chosen. See Kconfig.zephyr.")
endif()
Build: Improve C++ support Can choose the C++ standard (C++98/11/14/17/2a) Can link with standard C++ library (libstdc++) Add support of C++ exceptions Add support of C++ RTTI Add C++ options to subsys/cpp/Kconfig Implements new and delete using k_malloc and k_free if CONFIG_HEAP_MEM_POOL_SIZE is defined Signed-off-by: Benoit Leforestier <benoit.leforestier@gmail.com>
2018-10-23 18:20:51 +02:00
c++: kconfig: Fix choice dependencies and use 'menuconfig' symbol - Make the 'C++ Standard' choice depend on CPLUSPLUS, so that it only shows up when C++ support is enabled. Also check that CPLUSPLUS is enabled before checking the standard in the top-level CMakeLists.txt, to avoid triggering an assert. - The 'C++ Options' menu now contains just CPLUSPLUS and its indented children. Remove one menu level by removing the menu and turning CPLUSPLUS into a 'menuconfig' symbol. Also change the prompt from "Enable C++ support for the application" to just "C++ support for the application", to make it consistent with e.g. "Logging". - Factor out the common CPLUSPLUS dependency with an 'if CPLUSPLUS'. - Order symbol properties more consistently with other Kconfig files, with the prompt at the top, etc. Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2019-05-15 23:01:58 +02:00
foreach(flag ${STD_CPP_DIALECT_FLAGS})
zephyr_compile_options(
$<$<COMPILE_LANGUAGE:CXX>:${flag}>
)
endforeach()
endif()
cmake: Toolchain abstraction: C++ Introduce toolchain_cc_cpp_*-family of macros. Move the following into the toolchain_cc_cpp_* macros: * Common base set of flags * C++ standard version * RTTI * Exceptions These macros must be implemented by every compiler port. These macros set the respective flags, but leaves logic and control to the root CMakeLists.txt file. No functional change expected. Clang's C++ flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-02-18 23:54:30 +01:00
if(NOT CONFIG_EXCEPTIONS)
# @Intent: Obtain compiler specific flags related to C++ Exceptions
toolchain_cc_cpp_no_exceptions_flag(CPP_NO_EXCEPTIONS_FLAG)
zephyr_compile_options(
$<$<COMPILE_LANGUAGE:CXX>:${CPP_NO_EXCEPTIONS_FLAG}>
)
endif()
if(NOT CONFIG_RTTI)
# @Intent: Obtain compiler specific flags related to C++ Run Time Type Information
toolchain_cc_cpp_no_rtti_flag(CPP_NO_RTTI_FLAG)
zephyr_compile_options(
$<$<COMPILE_LANGUAGE:CXX>:${CPP_NO_RTTI_FLAG}>
)
endif()
lib/os: Conditionally eliminate alloca/VLA usage MISRA rules (see #9892) forbid alloca() and family, even though those features can be valuable performance and memory size optimizations useful to Zephyr. Introduce a MISRA_SANE kconfig, which when true enables a gcc error condition whenever a variable length array is used. When enabled, the mempool code will use a theoretical-maximum array size on the stack instead of one tailored to the current pool configuration. The rbtree code will do similarly, but because the theoretical maximum is quite a bit larger (236 bytes on 32 bit platforms) the array is placed into struct rbtree instead so it can live in static data (and also so I don't have to go and retune all the test stack sizes!). Current code only uses at most two of these (one in the scheduler when SCHED_SCALABLE is selected, and one for dynamic kernel objects when USERSPACE and DYNAMIC_OBJECTS are set). This tunable is false by default, but is selected in a single test (a subcase of tests/kernel/common) for coverage. Note that the I2C and SPI subsystems contain uncorrected VLAs, so a few platforms need to be blacklisted with a filter. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-02-27 20:53:18 +01:00
if(CONFIG_MISRA_SANE)
cmake: Toolchain abstraction: Introduce macros for MISRA SANE flags The macros are named toolchain_cc_warning_error_misra_sane and toolchain_cc_cpp_warning_error_misra_sane These macros provide toolchain specific flag(s) relating to the MISRA SANE configuration option. The macros will place the flag(s) in a variable provided by caller, which can then add to zephyr compile options. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-16 12:53:58 +02:00
# @Intent: Obtain toolchain compiler flags relating to MISRA.
toolchain_cc_warning_error_misra_sane(CC_MISRA_SANE_FLAG)
toolchain_cc_cpp_warning_error_misra_sane(CPP_MISRA_SANE_FLAG)
zephyr_compile_options($<$<COMPILE_LANGUAGE:C>:${CC_MISRA_SANE_FLAG}>)
zephyr_compile_options($<$<COMPILE_LANGUAGE:CXX>:${CPP_MISRA_SANE_FLAG}>)
lib/os: Conditionally eliminate alloca/VLA usage MISRA rules (see #9892) forbid alloca() and family, even though those features can be valuable performance and memory size optimizations useful to Zephyr. Introduce a MISRA_SANE kconfig, which when true enables a gcc error condition whenever a variable length array is used. When enabled, the mempool code will use a theoretical-maximum array size on the stack instead of one tailored to the current pool configuration. The rbtree code will do similarly, but because the theoretical maximum is quite a bit larger (236 bytes on 32 bit platforms) the array is placed into struct rbtree instead so it can live in static data (and also so I don't have to go and retune all the test stack sizes!). Current code only uses at most two of these (one in the scheduler when SCHED_SCALABLE is selected, and one for dynamic kernel objects when USERSPACE and DYNAMIC_OBJECTS are set). This tunable is false by default, but is selected in a single test (a subcase of tests/kernel/common) for coverage. Note that the I2C and SPI subsystems contain uncorrected VLAs, so a few platforms need to be blacklisted with a filter. Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
2019-02-27 20:53:18 +01:00
endif()
cmake: Toolchain abstraction: Introducing macro toolchain_cc_imacros The macro is intended to abstract the -imacros compiler option for inclusion of the autoconf.h header file. The abstraction allows for a given toolchain to decide how the inclusion of the header file is to be done. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-06-11 13:55:53 +02:00
# @Intent: Set compiler specific macro inclusion of AUTOCONF_H
toolchain_cc_imacros(${AUTOCONF_H})
cmake: Toolchain abstraction: Introducing toolchain_cc_freestanding The macro is intended to abstract the -ffreestanding compiler option which tells the compiler that this is a bare metal env. The option is compiler and thus toolchain specific, but this macro leaves it up to the toolchain to decide the value of the option. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-06-11 15:56:57 +02:00
# @Intent: Set compiler specific flag for bare metal freestanding option
toolchain_cc_freestanding()
cmake: Toolchain abstraction: Introducing macro toolchain_cc_nocommon The macro is intended to abstract the -fno-common compiler option which controls the placement of uninitialized global variables. The macro leaves it up to the toolchain to define the option. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-06-12 14:56:46 +02:00
# @Intent: Set compiler specific flag for tentative definitions, no-common
toolchain_cc_nocommon()
cmake: Toolchain abstraction: Abstract compiler flag for add debug info The macro, toolchain_cc_produce_debug_info, adds the compiler specific flag for enabling the production of debugging information in the toolchain native format. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-07-23 09:00:55 +02:00
# @Intent: Set compiler specific flag for production of debug information
toolchain_cc_produce_debug_info()
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_compile_options(
xtensa: provide XCC compiler support for Xtensa This patchset provides Xtensa's xcc compiler support for Xtensa projects in Cmake. This requires the below environment variables to be defined aptly. The appropriate xcc license information also need to be supplied. ZEPHYR_GCC_VARIANT=xcc TOOLCHAIN_VER=RF-2015.3-linux XTENSA_CORE=cavs21_LX6HiFi3_RF3_WB16 XTENSA_SYSTEM=/opt/xtensa/XtDevTools/install/tools/ RF-2015.3-linux/XtensaTools/config/ XTENSA_BUILD_PATHS=/opt/xtensa/XtDevTools/install/builds/ Change-Id: Ib3c10e8095439b0e32276ff37c00eca8420773ec Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-12 18:59:37 +01:00
${TOOLCHAIN_C_FLAGS}
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: Toolchain abstraction: Assembly Introduce toolchain_cc_asm macro to capture toolchain specific flags related to assembly. -D_ASMLANGUAGE is kept common for all, assuming -D as define flag is supported by all compilers (which is almost the case). No functional change expected. Clang's flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-30 21:48:25 +01:00
# @Intent: Obtain compiler specific flags related to assembly
toolchain_cc_asm_base_flags(ASM_BASE_FLAG)
zephyr_compile_options(
$<$<COMPILE_LANGUAGE:ASM>:${ASM_BASE_FLAG}>
)
CMakeLists.txt: parse zephyr_stdint.h after compiler specific flags The zephyr_stdint.h file enforces Zephyr specific policies on the compilation environment. Let's give compilers a chance to provide definitions of their own via TOOLCHAIN_C_FLAGS prior the inclusion of zephyr_stdint.h. Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
2019-07-02 22:22:04 +02:00
# @Intent: Enforce standard integer type correspondance to match Zephyr usage.
# (must be after compiler specific flags)
toolchain_cc_imacros(${ZEPHYR_BASE}/include/toolchain/zephyr_stdint.h)
cmake: Toolchain abstraction: Assembly Introduce toolchain_cc_asm macro to capture toolchain specific flags related to assembly. -D_ASMLANGUAGE is kept common for all, assuming -D as define flag is supported by all compilers (which is almost the case). No functional change expected. Clang's flags are compatible with gcc, and are thus inherited. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting easier porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-01-30 21:48:25 +01:00
# Common toolchain-agnostic assembly flags
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_compile_options(
$<$<COMPILE_LANGUAGE:ASM>:-D_ASMLANGUAGE>
)
cmake: Toolchain abstraction: use LINKER, introduce toolchain_ld_base toolchain_ld_base() represents flags that are fundamental to linking or otherwise does not belong in any further specified linker flag category. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-25 15:46:11 +02:00
# @Intent: Set fundamental linker specific flags
toolchain_ld_base()
arch: ARM: set -mthumb, -mcpu, -mfpu and -mfloat-abi in linker flags Some toolchains are built with multilib enabled in order to provide multiple versions of the same library, optimized for different ABI or architecture. They require the the ABI/architecture/CPU selection options to be passed at linked time. This is important for example when linking with newlib. Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
2018-11-26 13:48:34 +01:00
cmake: Introduce toolchain_ld_link_elf to abstract linker invocation Final step of linker abstraction: * Abstract zephyr_lnk by including it in toolchain_ld_link_elf. * Abstract relevant uses of target_link_libraries. * Introduce toolchain_ld_force_undefined_symbols. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 16:32:36 +02:00
toolchain_ld_force_undefined_symbols(
_OffsetAbsSyms
_ConfigAbsSyms
)
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
if(NOT CONFIG_NATIVE_APPLICATION)
cmake: Toolchain abstraction: introduce toolchain_ld_baremetal() The intent of toolchain_ld_baremetal() is to collect the flags belonging to non-hosted (i.e. POSIX-based) targets. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-25 16:31:30 +02:00
# @Intent: Set linker specific flags for bare metal target
toolchain_ld_baremetal()
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
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
Build: Improve C++ support Can choose the C++ standard (C++98/11/14/17/2a) Can link with standard C++ library (libstdc++) Add support of C++ exceptions Add support of C++ RTTI Add C++ options to subsys/cpp/Kconfig Implements new and delete using k_malloc and k_free if CONFIG_HEAP_MEM_POOL_SIZE is defined Signed-off-by: Benoit Leforestier <benoit.leforestier@gmail.com>
2018-10-23 18:20:51 +02:00
if(CONFIG_LIB_CPLUSPLUS)
cmake: Toolchain abstraction: introduce toolchain_ld_cpp No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-26 08:43:04 +02:00
# @Intent: Set linker specific flags for C++
toolchain_ld_cpp()
Build: Improve C++ support Can choose the C++ standard (C++98/11/14/17/2a) Can link with standard C++ library (libstdc++) Add support of C++ exceptions Add support of C++ RTTI Add C++ options to subsys/cpp/Kconfig Implements new and delete using k_malloc and k_free if CONFIG_HEAP_MEM_POOL_SIZE is defined Signed-off-by: Benoit Leforestier <benoit.leforestier@gmail.com>
2018-10-23 18:20:51 +02:00
endif()
cmake: Toolchain abstraction: Added missing colon to some <at>Intent's No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-16 12:49:31 +02:00
# @Intent: Add the basic toolchain warning flags
cmake: Toolchain abstraction: Introduce toolchain_cc_warning_base This is placeholder for base warning flags, common to most toolchains. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-06 15:19:27 +02:00
toolchain_cc_warning_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
# ==========================================================================
#
# cmake -DW=... settings
#
# W=1 - warnings that may be relevant and does not occur too often
# W=2 - warnings that occur quite often but may still be relevant
# W=3 - the more obscure warnings, can most likely be ignored
# ==========================================================================
cmake: Toolchain abstraction: Added missing colon to some <at>Intent's No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-16 12:49:31 +02:00
# @Intent: Add cmake -DW toolchain supported warnings, if any
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(W MATCHES "1")
cmake: Toolchain abstraction: Introduce toolchain_cc_warning_dw_[1-3] The introduced macros are placeholders for the cmake parameter warning level. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-06 14:34:43 +02:00
toolchain_cc_warning_dw_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
endif()
if(W MATCHES "2")
cmake: Toolchain abstraction: Introduce toolchain_cc_warning_dw_[1-3] The introduced macros are placeholders for the cmake parameter warning level. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-06 14:34:43 +02:00
toolchain_cc_warning_dw_2()
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
endif()
if(W MATCHES "3")
cmake: Toolchain abstraction: Introduce toolchain_cc_warning_dw_[1-3] The introduced macros are placeholders for the cmake parameter warning level. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-06 14:34:43 +02:00
toolchain_cc_warning_dw_3()
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
endif()
cmake: Toolchain abstraction: Added missing colon to some <at>Intent's No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-16 12:49:31 +02:00
# @Intent: Add extended, more specific, toolchain warning flags
cmake: Toolchain abstraction: Introduce toolchain_cc_warning_extended This is placeholder for extended warning flags, likely to change between toolchains. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-06 15:21:58 +02:00
toolchain_cc_warning_extended()
C++: Suppress warning The "register" keyword was deprecated since C++11. Add -Wno-register flag for avoid warning, with recent version of C++. Signed-off-by: Benoit Leforestier <benoit.leforestier@gmail.com>
2019-01-25 13:57:03 +01:00
cmake: Toolchain abstraction: Abstraction of implicit-int error flag Introducing the macro toolchain_cc_warning_error_implicit_int which, abstracts the implicit_int error flag thus leaving it to the toolchain to decide whether this flag is needed or not. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-16 12:58:40 +02:00
# @Intent: Trigger an error when a declaration does not specify a type
toolchain_cc_warning_error_implicit_int()
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
# Allow the user to inject options when calling cmake, e.g.
# 'cmake -DEXTRA_CFLAGS="-Werror -Wno-deprecated-declarations" ..'
cmake: Refactored EXTRA_FLAGS code into a dedicated script Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-10 12:22:23 +01:00
include(cmake/extra_flags.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
zephyr_cc_option(-fno-asynchronous-unwind-tables)
zephyr_cc_option(-fno-pie)
zephyr_cc_option(-fno-pic)
zephyr_cc_option(-fno-strict-overflow)
if(CONFIG_OVERRIDE_FRAME_POINTER_DEFAULT)
if(CONFIG_OMIT_FRAME_POINTER)
zephyr_cc_option(-fomit-frame-pointer)
else()
zephyr_cc_option(-fno-omit-frame-pointer)
endif()
endif()
cmake: Rename CMake variable out of the reserved CONFIG_ namespace Rename the poorly named CMake variable 'CONFIG_COMPILER_OPT_AS_LIST' to 'COMPILER_OPT_AS_LIST' to take it out of the Kconfig-reserved namespace 'CONFIG_*'. This is a small step towards resolving #12144 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-27 08:28:25 +01:00
separate_arguments(COMPILER_OPT_AS_LIST UNIX_COMMAND ${CONFIG_COMPILER_OPT})
zephyr_compile_options(${COMPILER_OPT_AS_LIST})
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
# TODO: Include arch compiler options at this point.
cmake: Toolchain abstraction: Introduce toolchain_cc_warning_extended This is placeholder for extended warning flags, likely to change between toolchains. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-05-06 15:21:58 +02:00
if(NOT CMAKE_C_COMPILER_ID STREQUAL "Clang")
# GCC assumed
zephyr_cc_option(-fno-reorder-functions)
xtensa: provide XCC compiler support for Xtensa This patchset provides Xtensa's xcc compiler support for Xtensa projects in Cmake. This requires the below environment variables to be defined aptly. The appropriate xcc license information also need to be supplied. ZEPHYR_GCC_VARIANT=xcc TOOLCHAIN_VER=RF-2015.3-linux XTENSA_CORE=cavs21_LX6HiFi3_RF3_WB16 XTENSA_SYSTEM=/opt/xtensa/XtDevTools/install/tools/ RF-2015.3-linux/XtensaTools/config/ XTENSA_BUILD_PATHS=/opt/xtensa/XtDevTools/install/builds/ Change-Id: Ib3c10e8095439b0e32276ff37c00eca8420773ec Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-12 18:59:37 +01:00
build: deprecate ZEPHYR_GCC_VARIANT We want to support other toolchain not based on GCC, so the variable is confusing, use ZEPHYR_TOOLCHAIN_VARIANT instead. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-02-11 21:36:21 +01:00
if(NOT ${ZEPHYR_TOOLCHAIN_VARIANT} STREQUAL "xcc")
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_cc_option(-fno-defer-pop)
endif()
endif()
zephyr_cc_option_ifdef(CONFIG_STACK_USAGE -fstack-usage)
cmake: zephyr_cc_option(-fmacro-prefix-map=${ZEPHYR_BASE}=.) If the compiler supports it, strip the ${ZEPHYR_BASE} prefix from the __FILE__ macro used in __ASSERT* macros, in the .noinit."/home/joe/zephyr/fu/bar.c" section names and in any application code. This saves some memory, stops leaking user locations in binaries, makes failure logs more deterministic and most importantly makes builds more deterministic. - .noinit section names now look like this in objdump -h: 17 .noinit."./kernel/init.c".2 00001100 00000000 ... 18 .noinit."./kernel/init.c".1 00001200 00000000 ... 19 .noinit."./kernel/init.c".3 00001800 00000000 ... - The output of __ASSERT* macros now looks like this: ASSERTION FAIL [0] @ ./samples/hello_world/src/main.c:13 The world comes crashing down ***** Kernel Panic! ***** Current thread ID = 0x00400040 Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-12 01:34:04 +02:00
# If the compiler supports it, strip the ${ZEPHYR_BASE} prefix from the
# __FILE__ macro used in __ASSERT*, in the
# .noinit."/home/joe/zephyr/fu/bar.c" section names and in any
# application code. This saves some memory, stops leaking user locations
# in binaries, makes failure logs more deterministic and most
# importantly makes builds more deterministic
CMakeLists.txt: -fmacro-prefix-map=${CMAKE_SOURCE_DIR}=CMAKE_SOURCE_DIR In commit 28a5657f1ff6d we stopped ZEPHYR_BASE from leaking into __FILE__ and other macros. This works great for apps inside ZEPHYR_BASE but does nothing for apps outside ZEPHYR_BASE. -fmacro-prefix-map=${CMAKE_SOURCE_DIR}=CMAKE_SOURCE_DIR does it. To avoid collisions and for consistency change: -fmacro-prefix-map=${ZEPHYR_BASE}=. to: -fmacro-prefix-map=${ZEPHYR_BASE}=ZEPHYR_BASE Quickest test/demo: - Copy samples/hello_word/ to ~/home_world/ - Add "%s", __FILE__ to printf in ~/home_world/src/main.c cmake -B build -S ~/home_world/ -DBOARD=qemu_x86 make -C build run Before: ~/home_world/src/main.c says Hello World! qemu_x86 After: CMAKE_SOURCE_DIR/src/main.c says Hello World! qemu_x86 objdump -h $(find build -name *.c.obj) | grep noinit 9 .noinit."ZEPHYR_BASE/kernel/system_work_q.c".0 0000 17 .noinit."ZEPHYR_BASE/kernel/init.c".2 00000100 000 18 .noinit."ZEPHYR_BASE/kernel/init.c".1 00000400 000 19 .noinit."ZEPHYR_BASE/kernel/init.c".3 00000800 000 16 .noinit."ZEPHYR_BASE/kernel/mailbox.c".2 00000348 18 .noinit."ZEPHYR_BASE/kernel/mailbox.c".1 00000028 20 .noinit."ZEPHYR_BASE/kernel/pipes.c".2 00000280 00 22 .noinit."ZEPHYR_BASE/kernel/pipes.c".1 00000028 00 Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-01 00:28:38 +02:00
# If both match then the last one wins. This matters for tests/ and
# samples/ inside *both* CMAKE_SOURCE_DIR and ZEPHYR_BASE: for them
# let's strip the shortest prefix.
zephyr_cc_option(-fmacro-prefix-map=${CMAKE_SOURCE_DIR}=CMAKE_SOURCE_DIR)
zephyr_cc_option(-fmacro-prefix-map=${ZEPHYR_BASE}=ZEPHYR_BASE)
# TODO: -fmacro-prefix-map=modules/etc. "build/zephyr_modules.txt" might help.
cmake: zephyr_cc_option(-fmacro-prefix-map=${ZEPHYR_BASE}=.) If the compiler supports it, strip the ${ZEPHYR_BASE} prefix from the __FILE__ macro used in __ASSERT* macros, in the .noinit."/home/joe/zephyr/fu/bar.c" section names and in any application code. This saves some memory, stops leaking user locations in binaries, makes failure logs more deterministic and most importantly makes builds more deterministic. - .noinit section names now look like this in objdump -h: 17 .noinit."./kernel/init.c".2 00001100 00000000 ... 18 .noinit."./kernel/init.c".1 00001200 00000000 ... 19 .noinit."./kernel/init.c".3 00001800 00000000 ... - The output of __ASSERT* macros now looks like this: ASSERTION FAIL [0] @ ./samples/hello_world/src/main.c:13 The world comes crashing down ***** Kernel Panic! ***** Current thread ID = 0x00400040 Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-12 01:34:04 +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
# TODO: Archiver arguments
# ar_option(D)
cmake: Move MPU userspace declaration up. This is done to make future modifications simpler, as more variables and functions are available. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 10:08:08 +01:00
# Declare MPU userspace dependencies before the linker scripts to make
# sure the order of dependencies are met
userspace: remove APPLICATION_MEMORY feature This was never a long-term solution, more of a gross hack to get test cases working until we could figure out a good end-to-end solution for memory domains that generated appropriate linker sections. Now that we have this with the app shared memory feature, and have converted all tests to remove it, delete this feature. To date all userspace APIs have been tagged as 'experimental' which sidesteps deprecation policies. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-01 00:53:24 +01:00
if(CONFIG_USERSPACE)
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
set(APP_SMEM_ALIGNED_DEP app_smem_aligned_linker)
set(APP_SMEM_UNALIGNED_DEP app_smem_unaligned_linker)
cmake: Move MPU userspace declaration up. This is done to make future modifications simpler, as more variables and functions are available. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 10:08:08 +01:00
if(CONFIG_ARM)
set(PRIV_STACK_DEP priv_stacks_prebuilt)
endif()
endif()
cmake: Move check for TOTP property up. This is done to make future modifications simpler, as more variables and functions are available. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 10:14:27 +01:00
get_property(TOPT GLOBAL PROPERTY TOPT)
cmake: clang: Make clang pick -T option on linking When linking, clang doesn't pick -T for some reason and complains, while -Wl,-T works for both, gcc and clang. Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
2019-03-08 10:29:33 +01:00
set_ifndef( TOPT -Wl,-T) # clang doesn't pick -T for some reason and complains,
# while -Wl,-T works for both, gcc and clang
cmake: Move check for TOTP property up. This is done to make future modifications simpler, as more variables and functions are available. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-29 10:14:27 +01: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
if(CONFIG_HAVE_CUSTOM_LINKER_SCRIPT)
set(LINKER_SCRIPT ${APPLICATION_SOURCE_DIR}/${CONFIG_CUSTOM_LINKER_SCRIPT})
cmake: Fix CONFIG_CUSTOM_LINKER_SCRIPT Specifying a custom linker script is supposed to be supported through Kconfig, but evidently this has been unused and 100% broken at least since the CMake migration. This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/6983 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-04-12 14:48:05 +02:00
if(NOT EXISTS ${LINKER_SCRIPT})
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(LINKER_SCRIPT ${CONFIG_CUSTOM_LINKER_SCRIPT})
cmake: Fix CONFIG_CUSTOM_LINKER_SCRIPT Specifying a custom linker script is supposed to be supported through Kconfig, but evidently this has been unused and 100% broken at least since the CMake migration. This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/6983 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-04-12 14:48:05 +02:00
assert_exists(CONFIG_CUSTOM_LINKER_SCRIPT)
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
endif()
else()
# Try a board specific linker file
set(LINKER_SCRIPT ${BOARD_DIR}/linker.ld)
if(NOT EXISTS ${LINKER_SCRIPT})
# If not available, try an SoC specific linker file
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
set(LINKER_SCRIPT ${SOC_DIR}/${ARCH}/${SOC_PATH}/linker.ld)
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
endif()
endif()
if(NOT EXISTS ${LINKER_SCRIPT})
message(FATAL_ERROR "Could not find linker script: '${LINKER_SCRIPT}'. Corrupted configuration?")
endif()
cmake: ld: add application source dir to linker script cpp command To enable using application-defined sections in linker scripts, the application source directory must be included in the search path when running the preprocessor to generate linker scripts. This prevents build failures when using any of the configuration options CONFIG_CUSTOM_RODATA_LD, CONFIG_CUSTOM_RWDATA_LD and CONFIG_CUSTOM_SECTIONS_LD. Signed-off-by: Kristian Klomsten Skordal <kristian.skordal@nordicsemi.no>
2018-01-30 11:26:42 +01:00
# Custom section support in linker scripts requires that the application source
# directory is in the preprocessor search path, in order to find the custom
# linker script fragments.
if(CONFIG_CUSTOM_RODATA_LD OR CONFIG_CUSTOM_RWDATA_LD OR CONFIG_CUSTOM_SECTIONS_LD)
zephyr_include_directories(${APPLICATION_SOURCE_DIR})
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
configure_file(version.h.in ${PROJECT_BINARY_DIR}/include/generated/version.h)
DeviceTree: Convert 'generated_dts_board.h' into a source file extract_dts_includes.py has been generating DT output and then concatenating it with fixup header files to create 'generated_dts_board.h'. In this patch we instead introduce a source file named 'generated_dts_board.h' and have it \#include the appropriate DT output and fixup files. This results in a simpler system because users can now read 'generated_dts_board.h' as C source code to see how fixup files and generated DT output relate to each other. Whereas before they would have to either read documentation or python code to gain the same understanding. Also, it reduces the scope and complexity of one of our most bloated python scripts, extract_dts_includes.py. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-10-09 16:03:29 +02:00
# Error-out when the deprecated naming convention is found (until
# after 1.14.0 has been released)
foreach(path
cmake: Various refactorings and whitespace fixes This commit applies various refactorings and whitespace fixes in preparation for the patch that fixes #13001. It includes changing indentation from tabs to spaces and splitting tokens across more lines to increase readability and minimize patch sizes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:39:37 +01:00
${BOARD_DIR}/dts.fixup
${PROJECT_SOURCE_DIR}/soc/${ARCH}/${SOC_PATH}/dts.fixup
DeviceTree: Convert 'generated_dts_board.h' into a source file extract_dts_includes.py has been generating DT output and then concatenating it with fixup header files to create 'generated_dts_board.h'. In this patch we instead introduce a source file named 'generated_dts_board.h' and have it \#include the appropriate DT output and fixup files. This results in a simpler system because users can now read 'generated_dts_board.h' as C source code to see how fixup files and generated DT output relate to each other. Whereas before they would have to either read documentation or python code to gain the same understanding. Also, it reduces the scope and complexity of one of our most bloated python scripts, extract_dts_includes.py. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-10-09 16:03:29 +02:00
${APPLICATION_SOURCE_DIR}/dts.fixup
cmake: Various refactorings and whitespace fixes This commit applies various refactorings and whitespace fixes in preparation for the patch that fixes #13001. It includes changing indentation from tabs to spaces and splitting tokens across more lines to increase readability and minimize patch sizes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:39:37 +01:00
)
DeviceTree: Convert 'generated_dts_board.h' into a source file extract_dts_includes.py has been generating DT output and then concatenating it with fixup header files to create 'generated_dts_board.h'. In this patch we instead introduce a source file named 'generated_dts_board.h' and have it \#include the appropriate DT output and fixup files. This results in a simpler system because users can now read 'generated_dts_board.h' as C source code to see how fixup files and generated DT output relate to each other. Whereas before they would have to either read documentation or python code to gain the same understanding. Also, it reduces the scope and complexity of one of our most bloated python scripts, extract_dts_includes.py. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-10-09 16:03:29 +02:00
if(EXISTS ${path})
cmake: Various refactorings and whitespace fixes This commit applies various refactorings and whitespace fixes in preparation for the patch that fixes #13001. It includes changing indentation from tabs to spaces and splitting tokens across more lines to increase readability and minimize patch sizes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:39:37 +01:00
message(FATAL_ERROR
"A deprecated filename has been detected. Porting is required."
"The file '${path}' exists, but it should be named dts_fixup.h instead."
"See https://github.com/zephyrproject-rtos/zephyr/pull/10352 for more details"
)
DeviceTree: Convert 'generated_dts_board.h' into a source file extract_dts_includes.py has been generating DT output and then concatenating it with fixup header files to create 'generated_dts_board.h'. In this patch we instead introduce a source file named 'generated_dts_board.h' and have it \#include the appropriate DT output and fixup files. This results in a simpler system because users can now read 'generated_dts_board.h' as C source code to see how fixup files and generated DT output relate to each other. Whereas before they would have to either read documentation or python code to gain the same understanding. Also, it reduces the scope and complexity of one of our most bloated python scripts, extract_dts_includes.py. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-10-09 16:03:29 +02:00
endif()
endforeach()
set_ifndef( DTS_BOARD_FIXUP_FILE ${BOARD_DIR}/dts_fixup.h)
set_ifndef( DTS_SOC_FIXUP_FILE ${SOC_DIR}/${ARCH}/${SOC_PATH}/dts_fixup.h)
set( DTS_APP_FIXUP_FILE ${APPLICATION_SOURCE_DIR}/dts_fixup.h)
cmake: Fix the generation of fixup files A recent change in how the fixup mechanism works caused several regressions. See https://github.com/zephyrproject-rtos/zephyr/pull/12680 for more details about the regressions. The core of the matter is that using defines to pass on include paths causes interopability issues when integrating with external build systems. To resolve this we re-write the fixup mechanism to instead generate an aggregated fixup file that is ready to be included at build time. Then no paths are passed through defines and we resolve the regressions reported. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-28 13:40:50 +01:00
set_ifndef(DTS_CAT_OF_FIXUP_FILES ${ZEPHYR_BINARY_DIR}/include/generated/generated_dts_board_fixups.h)
DeviceTree: Convert 'generated_dts_board.h' into a source file extract_dts_includes.py has been generating DT output and then concatenating it with fixup header files to create 'generated_dts_board.h'. In this patch we instead introduce a source file named 'generated_dts_board.h' and have it \#include the appropriate DT output and fixup files. This results in a simpler system because users can now read 'generated_dts_board.h' as C source code to see how fixup files and generated DT output relate to each other. Whereas before they would have to either read documentation or python code to gain the same understanding. Also, it reduces the scope and complexity of one of our most bloated python scripts, extract_dts_includes.py. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-10-09 16:03:29 +02:00
cmake: Fix the generation of fixup files A recent change in how the fixup mechanism works caused several regressions. See https://github.com/zephyrproject-rtos/zephyr/pull/12680 for more details about the regressions. The core of the matter is that using defines to pass on include paths causes interopability issues when integrating with external build systems. To resolve this we re-write the fixup mechanism to instead generate an aggregated fixup file that is ready to be included at build time. Then no paths are passed through defines and we resolve the regressions reported. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-28 13:40:50 +01:00
# Concatenate the fixups into a single header file for easy
# #include'ing
file(WRITE ${DTS_CAT_OF_FIXUP_FILES} "/* May only be included by generated_dts_board.h */\n\n")
foreach(fixup_file
cmake: Various refactorings and whitespace fixes This commit applies various refactorings and whitespace fixes in preparation for the patch that fixes #13001. It includes changing indentation from tabs to spaces and splitting tokens across more lines to increase readability and minimize patch sizes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:39:37 +01:00
${DTS_BOARD_FIXUP_FILE}
${DTS_SOC_FIXUP_FILE}
${DTS_APP_FIXUP_FILE}
${shield_dts_fixups}
)
cmake: Fix the generation of fixup files A recent change in how the fixup mechanism works caused several regressions. See https://github.com/zephyrproject-rtos/zephyr/pull/12680 for more details about the regressions. The core of the matter is that using defines to pass on include paths causes interopability issues when integrating with external build systems. To resolve this we re-write the fixup mechanism to instead generate an aggregated fixup file that is ready to be included at build time. Then no paths are passed through defines and we resolve the regressions reported. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-28 13:40:50 +01:00
if(EXISTS ${fixup_file})
cmake: Various refactorings and whitespace fixes This commit applies various refactorings and whitespace fixes in preparation for the patch that fixes #13001. It includes changing indentation from tabs to spaces and splitting tokens across more lines to increase readability and minimize patch sizes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:39:37 +01:00
file(READ ${fixup_file} contents)
file(APPEND ${DTS_CAT_OF_FIXUP_FILES} "${contents}")
DeviceTree: Convert 'generated_dts_board.h' into a source file extract_dts_includes.py has been generating DT output and then concatenating it with fixup header files to create 'generated_dts_board.h'. In this patch we instead introduce a source file named 'generated_dts_board.h' and have it \#include the appropriate DT output and fixup files. This results in a simpler system because users can now read 'generated_dts_board.h' as C source code to see how fixup files and generated DT output relate to each other. Whereas before they would have to either read documentation or python code to gain the same understanding. Also, it reduces the scope and complexity of one of our most bloated python scripts, extract_dts_includes.py. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-10-09 16:03:29 +02:00
endif()
endforeach()
cmake: Execute arch/CMakeLists.txt before subsys/CMakeList.txt Re-order the execution of the arch/ and subsys/ CMakeLists.txt code to work around a manifestation of issue #6505. When OpenThread created an External project in subsys, it did not have access to important toolchain flags added in arch/. Intuitively, subsystems might depends on how the ARCH is configured, but the ARCH shouldn't depend on any subsystem. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-09 10:52:57 +01:00
# Unfortunately, the order in which CMakeLists.txt code is processed
# matters so we need to be careful about how we order the processing
# of subdirectories. One example is "Compiler flags added late in the
# build are not exported to external build systems #5605"; when we
# integrate with an external build system we read out all compiler
# flags when the external project is created. So an external project
# defined in subsys or ext will not get global flags added by drivers/
# or tests/ as the subdirectories are ordered now.
#
# Another example of when the order matters is the reading and writing
# of global properties such as ZEPHYR_LIBS or
# GENERATED_KERNEL_OBJECT_FILES.
#
# Arch is placed early because it defines important compiler flags
# that must be exported to external build systems defined in
# e.g. subsys/.
add_subdirectory(arch)
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
add_subdirectory(lib)
# We use include instead of add_subdirectory to avoid creating a new directory scope.
# This is because source file properties are directory scoped, including the GENERATED
# property which is set implicitly for custom command outputs
include(misc/generated/CMakeLists.txt)
soc: adapt Kconfig/CMake for soc in top / Change build system to point to soc/ in the top directory rather than under arch/ Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-03 22:20:14 +02:00
cmake: Add zephyr base address when looking file into soc/ When checking availability of soc/${ARCH}/CMakeLists.txt, we should use ${ZEPHYR_BASE} as path base. Fixes #9956 Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
2018-09-13 16:25:53 +02:00
if(EXISTS ${SOC_DIR}/${ARCH}/CMakeLists.txt)
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
add_subdirectory(${SOC_DIR}/${ARCH} soc/${ARCH})
soc: adapt Kconfig/CMake for soc in top / Change build system to point to soc/ in the top directory rather than under arch/ Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-03 22:20:14 +02:00
else()
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
add_subdirectory(${SOC_DIR}/${ARCH}/${SOC_PATH} soc/${ARCH}/${SOC_PATH})
soc: adapt Kconfig/CMake for soc in top / Change build system to point to soc/ in the top directory rather than under arch/ Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2018-09-03 22:20:14 +02:00
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
add_subdirectory(boards)
add_subdirectory(ext)
add_subdirectory(subsys)
add_subdirectory(drivers)
cmake: Extracted Zephyr module processing into python script Fixes: #14513 This commit move the functionality of extracting zephyr modules into generated CMake and Kconfig include files from CMake into python. This allows other tools, especially CI to re-use the zephyr module functionality. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2019-03-19 10:38:18 +01:00
# Include zephyr modules generated CMake file.
if(EXISTS ${CMAKE_BINARY_DIR}/zephyr_modules.txt)
cmake: Encode and decode in UTF-8 in build system In order to make sure that the build works in folders that require a UTF encoding, make sure that both CMake and the various Python scripts that interact with each other on files use the same encoding, in this case UTF-8. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-07-18 10:38:25 +02:00
file(STRINGS ${CMAKE_BINARY_DIR}/zephyr_modules.txt ZEPHYR_MODULES_TXT
ENCODING UTF-8)
cmake: Extracted Zephyr module processing into python script Fixes: #14513 This commit move the functionality of extracting zephyr modules into generated CMake and Kconfig include files from CMake into python. This allows other tools, especially CI to re-use the zephyr module functionality. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2019-03-19 10:38:18 +01:00
foreach(module ${ZEPHYR_MODULES_TXT})
cmake: modules: Enclose name and path in quotes Due to the fact that CMake only supports greedy regexes, the ':' in a Windows path ('C:\...') was being matched leading to an invalid split of the line. Quote both the name and the path to avoid this issue. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-03-31 22:29:30 +02:00
# Match "<name>":"<path>" for each line of file, each corresponding to
# one module. The use of quotes is required due to CMake not supporting
# lazy regexes (it supports greedy only).
string(REGEX REPLACE "\"(.*)\":\".*\"" "\\1" module_name ${module})
string(REGEX REPLACE "\".*\":\"(.*)\"" "\\1" module_path ${module})
message("Including module: ${module_name} in path: ${module_path}")
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 the second, binary_dir parameter requires the added
# subdirectory to have its own, local cmake target(s). If not then
# this binary_dir is created but stays empty. Object files land in
# the main binary dir instead.
# https://cmake.org/pipermail/cmake/2019-June/069547.html
cmake: build modules under /modules As we start adding more modules, all of them end up in ${CMAKE_BINARY_DIR}/ and this is getting too busy. We have a module directory created for each module and the interesting build data is getting lost in the crowd. Move all module into ${CMAKE_BINARY_DIR}/modules to and keep them under one directory. Future enhancement: maintain the same structure of the modules as checked out by west. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-05-28 20:34:21 +02:00
add_subdirectory(${module_path} ${CMAKE_BINARY_DIR}/modules/${module_name})
cmake: Extracted Zephyr module processing into python script Fixes: #14513 This commit move the functionality of extracting zephyr modules into generated CMake and Kconfig include files from CMake into python. This allows other tools, especially CI to re-use the zephyr module functionality. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2019-03-19 10:38:18 +01:00
endforeach()
cmake: remove debug message if no modules are included in build. Fixes: #13245 Remove the printing of: 'Including module(s)' when no modules are included into the CMake build. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2019-02-12 10:19:38 +01:00
endif()
CMake/Kconfig: CMake and Kconfig build integration This commit allows for Zephyr modules to be natively integrated into the build system with CMakeLists.txt and Kconfig files. The sourcing of module files are done in following order: - If <module>/zephyr/module.yml exists, use cmake and kconfig settings for sourcing of additional file - Else if <module>/zephyr/CMakeLists.txt exists, source this file into CMake build tree and add <module>/zephyr/Kconfig as osource If none of the above files are present, the project is considered to not be a Zephyr module Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2019-02-05 10:36:22 +01:00
cmake: Move syscall_macros.h generation into the build stage This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5186 The script that generates syscall_macros.h is moved from Configuration time to build time. This allows us to express to the build system that syscall_macros.h depends on the script that generates it. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-29 17:46:37 +01:00
set(syscall_macros_h ${ZEPHYR_BINARY_DIR}/include/generated/syscall_macros.h)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_custom_target(${SYSCALL_MACROS_H_TARGET} DEPENDS ${syscall_macros_h})
cmake: whitespace alignment of syscall_macros_h No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 17:17:30 +02:00
add_custom_command( OUTPUT ${syscall_macros_h}
cmake: Move syscall_macros.h generation into the build stage This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5186 The script that generates syscall_macros.h is moved from Configuration time to build time. This allows us to express to the build system that syscall_macros.h depends on the script that generates it. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-29 17:46:37 +01:00
COMMAND
${PYTHON_EXECUTABLE}
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
${ZEPHYR_BASE}/scripts/gen_syscall_header.py
cmake: Move syscall_macros.h generation into the build stage This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5186 The script that generates syscall_macros.h is moved from Configuration time to build time. This allows us to express to the build system that syscall_macros.h depends on the script that generates it. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-29 17:46:37 +01:00
> ${syscall_macros_h}
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
DEPENDS ${ZEPHYR_BASE}/scripts/gen_syscall_header.py
cmake: Move syscall_macros.h generation into the build stage This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5186 The script that generates syscall_macros.h is moved from Configuration time to build time. This allows us to express to the build system that syscall_macros.h depends on the script that generates it. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-29 17:46:37 +01:00
)
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
set(syscall_list_h ${CMAKE_CURRENT_BINARY_DIR}/include/generated/syscall_list.h)
set(syscalls_json ${CMAKE_CURRENT_BINARY_DIR}/misc/generated/syscalls.json)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
# The syscalls subdirs txt file is constructed by python containing a list of folders to use for
# dependency handling, including empty folders.
# Windows: The list is used to specify DIRECTORY list with CMAKE_CONFIGURE_DEPENDS attribute.
# Other OS: The list will update whenever a file is added/removed/modified and ensure a re-build.
set(syscalls_subdirs_txt ${CMAKE_CURRENT_BINARY_DIR}/misc/generated/syscalls_subdirs.txt)
# As syscalls_subdirs_txt is updated whenever a file is modified, this file can not be used for
# monitoring of added / removed folders. A trigger file is thus used for correct dependency
# handling. The trigger file will update when a folder is added / removed.
set(syscalls_subdirs_trigger ${CMAKE_CURRENT_BINARY_DIR}/misc/generated/syscalls_subdirs.trigger)
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
if(NOT (${CMAKE_HOST_SYSTEM_NAME} STREQUAL Windows))
set(syscalls_links --create-links ${CMAKE_CURRENT_BINARY_DIR}/misc/generated/syscalls_links)
endif()
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
# When running CMake it must be ensured that all dependencies are correctly acquired.
execute_process(
COMMAND
${PYTHON_EXECUTABLE}
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
${ZEPHYR_BASE}/scripts/subfolder_list.py
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
--directory ${ZEPHYR_BASE}/include # Walk this directory
--out-file ${syscalls_subdirs_txt} # Write file with discovered folder
--trigger ${syscalls_subdirs_trigger} # Trigger file that is used for json generation
${syscalls_links} # If defined, create symlinks for dependencies
)
cmake: Encode and decode in UTF-8 in build system In order to make sure that the build works in folders that require a UTF encoding, make sure that both CMake and the various Python scripts that interact with each other on files use the same encoding, in this case UTF-8. Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
2019-07-18 10:38:25 +02:00
file(STRINGS ${syscalls_subdirs_txt} PARSE_SYSCALLS_PATHS_DEPENDS ENCODING UTF-8)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
if(${CMAKE_HOST_SYSTEM_NAME} STREQUAL Windows)
# On windows only adding/removing files or folders will be reflected in depends.
# Hence adding a file requires CMake to re-run to add this file to the file list.
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${PARSE_SYSCALLS_PATHS_DEPENDS})
# Also On Windows each header file must be monitored as file modifications are not reflected
# on directory level.
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
file(GLOB_RECURSE PARSE_SYSCALLS_HEADER_DEPENDS ${ZEPHYR_BASE}/include/*.h)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
else()
# The syscall parsing depends on the folders in order to detect add/removed/modified files.
# When a folder is removed, CMake will try to find a target that creates that dependency.
# This command sets up the target for CMake to find.
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
# Without this code, CMake will fail with the following error:
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
# <folder> needed by '<target>', missing and no known rule to make it
# when a folder is removed.
add_custom_command(OUTPUT ${PARSE_SYSCALLS_PATHS_DEPENDS}
COMMAND ${CMAKE_COMMAND} -E echo ""
COMMENT "Preparing syscall dependency handling"
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
add_custom_command(
OUTPUT
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
${syscalls_subdirs_trigger}
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
COMMAND
${PYTHON_EXECUTABLE}
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
${ZEPHYR_BASE}/scripts/subfolder_list.py
--directory ${ZEPHYR_BASE}/include # Walk this directory
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
--out-file ${syscalls_subdirs_txt} # Write file with discovered folder
--trigger ${syscalls_subdirs_trigger} # Trigger file that is used for json generation
${syscalls_links} # If defined, create symlinks for dependencies
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
DEPENDS ${PARSE_SYSCALLS_PATHS_DEPENDS}
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
)
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
# Ensure subdir file always exists when specifying CMake dependency.
if(NOT EXISTS ${syscalls_subdirs_txt})
file(WRITE ${syscalls_subdirs_txt} "")
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
endif()
# On other OS'es, modifying a file is reflected on the folder timestamp and hence detected
# when using depend on directory level.
# Thus CMake only needs to re-run when sub-directories are added / removed, which is indicated
# using a trigger file.
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${syscalls_subdirs_txt})
cmake: Update to dependency handling for syscalls.json Fixes: #8210 Following changes has been made to ensure correct behavior on different system: - Python script to detect changes to directories, including empty ones. When files are modified the list is updated If sub-directories are added / removed a trigger file is touched to notify cmake to re-run - Windows: To detect changes to header files in include for parse_syscalls.py all files must be individual monitored. Hence all headers are globbed added to dependencies. CMake configure depends on the folders so the added / removed files are picked up. - Other: Folders are monitored through the python list file so that added / remove / modified Added / removed sub-directories are detected through trigger file in order to re-run cmake. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-07 15:50:31 +02:00
endif()
syscalls: Scan multiple folders to build complete syscall list Previously the syscall list was generated only from the include folder. This is a limitation when the application tries to create system calls. This patch create a simple way to include these new syscalls without the application touching the kernel. This can be enabled by a Kconfig CONFIG_APPLICATION_DEFINED_SYSCALL. Once enabled the application source directory will be scanned to find all application defined syscalls. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-07-02 11:29:19 +02:00
# SYSCALL_INCLUDE_DIRECTORY will include the directories that needs to be
# searched for syscall declarations if CONFIG_APPLICATION_DEFINED_SYSCALL is set
if(CONFIG_APPLICATION_DEFINED_SYSCALL)
set(SYSCALL_INCLUDE_DIRECTORY --include ${APPLICATION_SOURCE_DIR})
endif()
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
add_custom_command(
OUTPUT
${syscalls_json}
COMMAND
${PYTHON_EXECUTABLE}
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
${ZEPHYR_BASE}/scripts/parse_syscalls.py
syscalls: Scan multiple folders to build complete syscall list Previously the syscall list was generated only from the include folder. This is a limitation when the application tries to create system calls. This patch create a simple way to include these new syscalls without the application touching the kernel. This can be enabled by a Kconfig CONFIG_APPLICATION_DEFINED_SYSCALL. Once enabled the application source directory will be scanned to find all application defined syscalls. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-07-02 11:29:19 +02:00
--include ${ZEPHYR_BASE}/include # Read files from this dir
${SYSCALL_INCLUDE_DIRECTORY}
cmake: Using symlinks on unix like os'es for dependencies Fixes: #8380 This commit fixes the side-effect of PR #8211 where a 'ninja clean' would try to remove dependency folders. Changes: - Symlinks are created during build and CMake targets now depends on the symlinks. Thus, same behavior is achived with regards to dependency handling, while at the same time, the output can be cleaned as the dependencies are now attached to the symlinks. - Dependencies have been changed so that generation of json files depends on the trigger file and CMake depends upon the subdir txt file. This prevents additional CMake runs after a clean. Signed-off-by: Torsten Rasmussen <torsten.rasmussen@nordicsemi.no>
2018-06-14 22:27:17 +02:00
--json-file ${syscalls_json} # Write this file
DEPENDS ${syscalls_subdirs_trigger} ${PARSE_SYSCALLS_HEADER_DEPENDS}
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_custom_target(${SYSCALL_LIST_H_TARGET} DEPENDS ${syscall_list_h})
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
add_custom_command(OUTPUT include/generated/syscall_dispatch.c ${syscall_list_h}
# Also, some files are written to include/generated/syscalls/
COMMAND
${PYTHON_EXECUTABLE}
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
${ZEPHYR_BASE}/scripts/gen_syscalls.py
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
--json-file ${syscalls_json} # Read this file
--base-output include/generated/syscalls # Write to this dir
--syscall-dispatch include/generated/syscall_dispatch.c # Write this file
gen_syscalls.py: do not output data to stdout There's no particularly good reason to have one kind of output from this script to be sent to stdout instead of a filename specified by parameter, and it makes it annoying to add debug print() statements. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-07-24 03:10:15 +02:00
--syscall-list ${syscall_list_h}
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
DEPENDS ${syscalls_json}
)
drivers: Perform a runtime check if a driver is capable of an operation Driver APIs might not implement all operations, making it possible for a user thread to get the kernel to execute a function at 0x00000000. Perform runtime checks in all the driver handlers, checking if they're capable of performing the requested operation. Fixes #6907. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-04 22:50:32 +02:00
set(DRV_VALIDATION ${PROJECT_BINARY_DIR}/include/generated/driver-validation.h)
add_custom_command(
OUTPUT ${DRV_VALIDATION}
COMMAND
${PYTHON_EXECUTABLE}
${ZEPHYR_BASE}/scripts/gen_kobject_list.py
--validation-output ${DRV_VALIDATION}
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
cmake: Fix missing dependency DRV_VALIDATION should depend on any changes to the tool that generates it, gen_kobject_list.py. Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
2019-04-12 18:00:52 +02:00
DEPENDS ${ZEPHYR_BASE}/scripts/gen_kobject_list.py
drivers: Perform a runtime check if a driver is capable of an operation Driver APIs might not implement all operations, making it possible for a user thread to get the kernel to execute a function at 0x00000000. Perform runtime checks in all the driver handlers, checking if they're capable of performing the requested operation. Fixes #6907. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-04 22:50:32 +02:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_custom_target(${DRIVER_VALIDATION_H_TARGET} DEPENDS ${DRV_VALIDATION})
drivers: Perform a runtime check if a driver is capable of an operation Driver APIs might not implement all operations, making it possible for a user thread to get the kernel to execute a function at 0x00000000. Perform runtime checks in all the driver handlers, checking if they're capable of performing the requested operation. Fixes #6907. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-04 22:50:32 +02:00
scripts: gen_kobject_list: Generate enums and case statements Adding a new kernel object type or driver subsystem requires changes in various different places. This patch makes it easier to create those devices by generating as much as possible in compile time. No behavior change. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-05 22:59:33 +02:00
include($ENV{ZEPHYR_BASE}/cmake/kobj.cmake)
gen_kobj(KOBJ_INCLUDE_PATH)
drivers: Perform a runtime check if a driver is capable of an operation Driver APIs might not implement all operations, making it possible for a user thread to get the kernel to execute a function at 0x00000000. Perform runtime checks in all the driver handlers, checking if they're capable of performing the requested operation. Fixes #6907. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-04 22:50:32 +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
# Generate offsets.c.obj from offsets.c
# Generate offsets.h from offsets.c.obj
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
set(OFFSETS_LIB offsets)
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
set(OFFSETS_C_PATH ${ARCH_DIR}/${ARCH}/core/offsets/offsets.c)
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(OFFSETS_H_PATH ${PROJECT_BINARY_DIR}/include/generated/offsets.h)
Build: Offsets lib as OBJECT not STATIC With the new cmake version, we are able to simplify the generation of the offset object library without using absolute hardcoded paths. Instead of the hardcoded paths, we now use the generator: $<TARGET_OBJECTS:${OFFSETS_LIB}> This is needed to eventually be able to have an arch-out-of-tree build Signed-off-by: Klaus Petersen <kape@oticon.com>
2019-02-04 12:10:57 +01:00
add_library( ${OFFSETS_LIB} OBJECT ${OFFSETS_C_PATH})
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
target_link_libraries(${OFFSETS_LIB} zephyr_interface)
add_dependencies( ${OFFSETS_LIB}
${SYSCALL_LIST_H_TARGET}
${SYSCALL_MACROS_H_TARGET}
${DRIVER_VALIDATION_H_TARGET}
${KOBJ_TYPES_H_TARGET}
cmake: Re-organize syscall generation wrt. the build system This commit fixes https://github.com/zephyrproject-rtos/zephyr/issues/5008. It does so by splitting up gen_syscalls.py into two scripts with a json metadata file to communicate syscall metadata between them. The parsing script parses header files from include/ and writes syscall metadata to a file if the contents changed. The generation script reads from the json file and generates syscall code. The build system DAG now looks like this: always_rebuild -> json -> syscalls -> offset.o The script for generating json will do so only if the content changes, this ensures that the entire DAG does not always do a full rebuild. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-11-20 13:03:55 +01: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
add_custom_command(
OUTPUT ${OFFSETS_H_PATH}
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 ${PYTHON_EXECUTABLE} ${ZEPHYR_BASE}/scripts/gen_offset_header.py
Build: Offsets lib as OBJECT not STATIC With the new cmake version, we are able to simplify the generation of the offset object library without using absolute hardcoded paths. Instead of the hardcoded paths, we now use the generator: $<TARGET_OBJECTS:${OFFSETS_LIB}> This is needed to eventually be able to have an arch-out-of-tree build Signed-off-by: Klaus Petersen <kape@oticon.com>
2019-02-04 12:10:57 +01:00
-i $<TARGET_OBJECTS:${OFFSETS_LIB}>
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
-o ${OFFSETS_H_PATH}
cmake: Fix dependency between offset.c.obj and offsets.h The command for generating offsets.h has only been depending on the target for offsets.c.obj, and not the file offsets.c.obj itself. Both are needed, as explained in "CMake: dependencies between targets and files and custom commands"[0]. This patch adds the dependency and fixes #18301 [0] https://tinyurl.com/y2hgzjhx Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-08-15 14:45:59 +02:00
DEPENDS
${OFFSETS_LIB}
$<TARGET_OBJECTS:${OFFSETS_LIB}>
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 variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_custom_target(${OFFSETS_H_TARGET} DEPENDS ${OFFSETS_H_PATH})
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_include_directories(${TOOLCHAIN_INCLUDES})
cmake: Change the zephyr_get_* API to be LANG-aware When exporting flags to an external build system we need to deal with the fact that we sometimes use generator expressions. Specifically, we use generator expressions that look like this: $<$<COMPILE_LANGUAGE:CXX>:-fno-exceptions> This patch replaces the old API with a new one where users can ask for compile options for specific languages, like this: zephyr_get_compile_options_for_lang_as_string(CXX x) The existing API would have either crashed or silently omitted flags when a COMPILE_LANG generator expression was present. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-01 15:25:06 +01:00
zephyr_get_include_directories_for_lang(C ZEPHYR_INCLUDES)
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
add_subdirectory(kernel)
# Read list content
get_property(ZEPHYR_LIBS_PROPERTY GLOBAL PROPERTY ZEPHYR_LIBS)
foreach(zephyr_lib ${ZEPHYR_LIBS_PROPERTY})
# TODO: Could this become an INTERFACE property of zephyr_interface?
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
add_dependencies(${zephyr_lib} ${OFFSETS_H_TARGET})
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
endforeach()
get_property(OUTPUT_FORMAT GLOBAL PROPERTY PROPERTY_OUTPUT_FORMAT)
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
if (CONFIG_CODE_DATA_RELOCATION)
set(CODE_RELOCATION_DEP code_relocation_source_lib)
endif() # CONFIG_CODE_DATA_RELOCATION
cmake: ld: Refactor the linker script's cpp command construction Construct the custom command for preprocessing the linker script with a function to avoid copy-paste errors between linker passes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-31 10:39:23 +01:00
cmake: rename construct_add_custom_command_for_linker_pass macro Now that we avoid the two-step procedure, we can simplify the name of the construct_add_custom_command_for_linker_pass macro. Move description comment up to head of definition, making the purpose clearer. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 17:16:54 +02:00
configure_linker_script(
cmake: configure_linker_script: accept argument with file extension Reduce the amount of {pre,post}fixing magic: I.e. let it be clearer at call sites that "linker.cmd" is a file, rather than having to know that "linker" will be postfixed with ".cmd" internally. Change argument name to linker_script_gen, to better indicate that we are producing a generated file. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 20:27:23 +02:00
linker.cmd
cmake: simplify configure_linker_script: avoid deriving define from name Rather than associating defines within the function, let the call sites themselves pick the appropriate define. Add new argument for this. This also permits us to remove regex matching. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 20:35:12 +02:00
""
cmake: Fix dependencies for LD script generation The dependencies relating to generating LD scripts are declared incorrectly. This manifests itself as broken incremental builds as shown in #13001. This commit aligns the LD script generation with the Zephyr standard for declaring custom commands. For instance, custom commands should generate files that are wrapped by targets. The custom commands should declare the dependencies, not the targets. Also, when using custom commands, the OUTPUT signature should be used, not the TARGET signature, as app_smem was doing. For details about how Zephyr uses custom commands see https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ This fixes #13001. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:49:57 +01:00
${PRIV_STACK_DEP}
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
${APP_SMEM_ALIGNED_DEP}
cmake: Fix dependencies for LD script generation The dependencies relating to generating LD scripts are declared incorrectly. This manifests itself as broken incremental builds as shown in #13001. This commit aligns the LD script generation with the Zephyr standard for declaring custom commands. For instance, custom commands should generate files that are wrapped by targets. The custom commands should declare the dependencies, not the targets. Also, when using custom commands, the OUTPUT signature should be used, not the TARGET signature, as app_smem was doing. For details about how Zephyr uses custom commands see https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ This fixes #13001. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:49:57 +01:00
${CODE_RELOCATION_DEP}
${OFFSETS_H_TARGET}
cmake: Various refactorings and whitespace fixes This commit applies various refactorings and whitespace fixes in preparation for the patch that fixes #13001. It includes changing indentation from tabs to spaces and splitting tokens across more lines to increase readability and minimize patch sizes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:39:37 +01:00
)
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01: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
add_custom_target(
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${LINKER_SCRIPT_TARGET}
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
DEPENDS
linker.cmd
cmake: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
)
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
# Give the '${LINKER_SCRIPT_TARGET}' target all of the include directories so
cmake: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
# that cmake can successfully find the linker_script's header
# dependencies.
zephyr_get_include_directories_for_lang(C
ZEPHYR_INCLUDE_DIRS
STRIP_PREFIX # Don't use a -I prefix
)
set_property(TARGET
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${LINKER_SCRIPT_TARGET}
cmake: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
PROPERTY INCLUDE_DIRECTORIES
${ZEPHYR_INCLUDE_DIRS}
)
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(CONFIG_GEN_ISR_TABLES)
xtensa: provide XCC compiler support for Xtensa This patchset provides Xtensa's xcc compiler support for Xtensa projects in Cmake. This requires the below environment variables to be defined aptly. The appropriate xcc license information also need to be supplied. ZEPHYR_GCC_VARIANT=xcc TOOLCHAIN_VER=RF-2015.3-linux XTENSA_CORE=cavs21_LX6HiFi3_RF3_WB16 XTENSA_SYSTEM=/opt/xtensa/XtDevTools/install/tools/ RF-2015.3-linux/XtensaTools/config/ XTENSA_BUILD_PATHS=/opt/xtensa/XtDevTools/install/builds/ Change-Id: Ib3c10e8095439b0e32276ff37c00eca8420773ec Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-12 18:59:37 +01:00
if(CONFIG_GEN_SW_ISR_TABLE)
list(APPEND GEN_ISR_TABLE_EXTRA_ARG --sw-isr-table)
endif()
if(CONFIG_GEN_IRQ_VECTOR_TABLE)
list(APPEND GEN_ISR_TABLE_EXTRA_ARG --vector-table)
endif()
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
# isr_tables.c is generated from ${ZEPHYR_PREBUILT_EXECUTABLE} by
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
# gen_isr_tables.py
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
set(obj_copy_cmd "")
bintools_objcopy(
RESULT_CMD_LIST obj_copy_cmd
TARGET_INPUT ${OUTPUT_FORMAT}
TARGET_OUTPUT "binary"
SECTION_ONLY ".intList"
FILE_INPUT $<TARGET_FILE:${ZEPHYR_PREBUILT_EXECUTABLE}>
FILE_OUTPUT "isrList.bin"
)
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
add_custom_command(
OUTPUT isr_tables.c
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
${obj_copy_cmd}
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
COMMAND ${PYTHON_EXECUTABLE}
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
${ZEPHYR_BASE}/arch/common/gen_isr_tables.py
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
--output-source isr_tables.c
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
--kernel $<TARGET_FILE:${ZEPHYR_PREBUILT_EXECUTABLE}>
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
--intlist isrList.bin
arch: add big endian support This patch adds Big Endian architecture support. Even if a compiler generating big endian object files is used, our linker script, or include/linker/linker-tool-gcc.h to be precise, has default output format as little endian. This patch adds a hidden config CONFIG_BIG_ENDIAN, which should be set by big endian architectures or a SoC's, and adds an condition to switch OUTPUT_FORMAT in our linker.cmd. Signed-off-by: Yasushi SHOJI <y-shoji@ispace-inc.com>
2018-10-09 11:59:16 +02:00
$<$<BOOL:${CONFIG_BIG_ENDIAN}>:--big-endian>
cmake: gen_isr_tables: Reduce verbosity of non-verbose builds. gen_isr_tables.py's --debug flag causes it to spit out a verbose log. Normal builds don't need to see this information. This patch will remove this from the build log: gen_isr_tables.py: (4041, 4477, 46, 0, 7) gen_isr_tables.py: spurious handler: 0xfc9 gen_isr_tables.py: Configured interrupt routing gen_isr_tables.py: handler irq flags param gen_isr_tables.py: -------------------------- gen_isr_tables.py: 0x14bd 0 0 0x0 gen_isr_tables.py: 0x16a1 6 0 0x20002bac gen_isr_tables.py: 0x1975 17 0 0x0 gen_isr_tables.py: 0x7e5b 13 0 0x0 gen_isr_tables.py: 0x7e55 24 0 0x0 gen_isr_tables.py: 0x7e21 11 0 0x0 gen_isr_tables.py: 0x7e5f 1 1 0x0 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-04 14:08:39 +01:00
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--debug>
xtensa: provide XCC compiler support for Xtensa This patchset provides Xtensa's xcc compiler support for Xtensa projects in Cmake. This requires the below environment variables to be defined aptly. The appropriate xcc license information also need to be supplied. ZEPHYR_GCC_VARIANT=xcc TOOLCHAIN_VER=RF-2015.3-linux XTENSA_CORE=cavs21_LX6HiFi3_RF3_WB16 XTENSA_SYSTEM=/opt/xtensa/XtDevTools/install/tools/ RF-2015.3-linux/XtensaTools/config/ XTENSA_BUILD_PATHS=/opt/xtensa/XtDevTools/install/builds/ Change-Id: Ib3c10e8095439b0e32276ff37c00eca8420773ec Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-12 18:59:37 +01:00
${GEN_ISR_TABLE_EXTRA_ARG}
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
DEPENDS ${ZEPHYR_PREBUILT_EXECUTABLE}
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_property(GLOBAL APPEND PROPERTY GENERATED_KERNEL_SOURCE_FILES isr_tables.c)
endif()
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
if(CONFIG_CODE_DATA_RELOCATION)
cmake: Toolchain abstraction: Introduce toolchain_ld_relocation macro No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-03 10:33:03 +02:00
# @Intent: Linker script to relocate .text, data and .bss sections
toolchain_ld_relocation()
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
endif()
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
if(CONFIG_USERSPACE)
zephyr_get_compile_options_for_lang_as_string(C compiler_flags_priv)
string(REPLACE "-ftest-coverage" "" NO_COVERAGE_FLAGS "${compiler_flags_priv}")
string(REPLACE "-fprofile-arcs" "" NO_COVERAGE_FLAGS "${NO_COVERAGE_FLAGS}")
codecov: keep "inline" for ALWAYS_INLINE Previous commit c31e659165e9b55a5712f9298a63782de1725878 changed the ALWAYS_INLINE macros to avoid functions being inlined for the purpose of code coverage. This has a side effect of causing the text sections of kobject_hash.c and priv_stacks_hash.c to ballon more than 10 times in size. This is caused by attaching the unused attribute, which results in all those functions being in the text sections though they are never used. So just keep the "inline" there. This also removes -fno-inline from NO_COVERAGE_FLAGS so these two files are not compiled with flags related to code coverage. Fixes #15009 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-04-02 00:57:35 +02:00
string(REPLACE "-fno-inline" "" NO_COVERAGE_FLAGS "${NO_COVERAGE_FLAGS}")
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
get_property(include_dir_in_interface TARGET zephyr_interface
PROPERTY INTERFACE_INCLUDE_DIRECTORIES)
get_property(sys_include_dir_in_interface TARGET zephyr_interface
PROPERTY INTERFACE_SYSTEM_INCLUDE_DIRECTORIES)
get_property(compile_definitions_interface TARGET zephyr_interface
PROPERTY INTERFACE_COMPILE_DEFINITIONS)
endif()
gen_kobject_list.py: better comments and --help. Zero code change. - The script can but does not always generate five files, in fact the current build invokes it at least three times requesting different outputs every time. - --kobj-types-output produces a code fragment; not a standalone/usable header file. It outputs enum constants for a single enum type and not several enum types. - Some outputs include driver instances and others not: clarify which. - There's an entire and great section in the documentation that took me ages to find because it's not referenced anywhere in the --help or code. Fixed. - Highlight the massive duplication in the CMakeLists.txt to save déjà vu confusion and minimize future divergence. - Other minor tweaks. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-17 00:39:45 +02:00
# Warning most of this gperf code is duplicated below for
# gen_kobject_list.py / output_lib
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
if(CONFIG_ARM AND CONFIG_USERSPACE)
set(GEN_PRIV_STACKS $ENV{ZEPHYR_BASE}/scripts/gen_priv_stacks.py)
set(PROCESS_PRIV_STACKS_GPERF $ENV{ZEPHYR_BASE}/scripts/process_gperf.py)
set(PRIV_STACKS priv_stacks_hash.gperf)
set(PRIV_STACKS_OUTPUT_SRC_PRE priv_stacks_hash_preprocessed.c)
set(PRIV_STACKS_OUTPUT_SRC priv_stacks_hash.c)
set(PRIV_STACKS_OUTPUT_OBJ priv_stacks_hash.c.obj)
set(PRIV_STACKS_OUTPUT_OBJ_RENAMED priv_stacks_hash_renamed.o)
# Essentially what we are doing here is extracting some information
# out of the nearly finished elf file, generating the source code
# for a hash table based on that information, and then compiling and
# linking the hash table back into a now even more nearly finished
# elf file.
# Use the script GEN_PRIV_STACKS to scan the kernel binary's
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
# (${ZEPHYR_PREBUILT_EXECUTABLE}) DWARF information to produce a table of kernel
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
# objects (PRIV_STACKS) which we will then pass to gperf
add_custom_command(
OUTPUT ${PRIV_STACKS}
COMMAND
${PYTHON_EXECUTABLE}
${GEN_PRIV_STACKS}
--kernel $<TARGET_FILE:priv_stacks_prebuilt>
--output ${PRIV_STACKS}
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
DEPENDS priv_stacks_prebuilt
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(priv_stacks DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS})
# Use gperf to generate C code (PRIV_STACKS_OUTPUT_SRC_PRE) which implements a
# perfect hashtable based on PRIV_STACKS
add_custom_command(
OUTPUT ${PRIV_STACKS_OUTPUT_SRC_PRE}
COMMAND
${GPERF} -C
--output-file ${PRIV_STACKS_OUTPUT_SRC_PRE}
${PRIV_STACKS}
makefile: Fix dependencies for privileged stacks This patch fixes the dependency chain for priviliged stack generation. This fixes a problem when compiling after making significant changes that would shift the privileged stack area. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-05-01 08:10:26 +02:00
DEPENDS priv_stacks ${PRIV_STACKS}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(priv_stacks_output_src_pre DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC_PRE})
# For our purposes the code/data generated by gperf is not optimal.
#
# The script PROCESS_GPERF creates a new c file OUTPUT_SRC based on
# OUTPUT_SRC_PRE to greatly reduce the amount of code/data generated
# since we know we are always working with pointer values
add_custom_command(
OUTPUT ${PRIV_STACKS_OUTPUT_SRC}
COMMAND
cmake: Invoke 'python' instead of py scripts directly Python scripts should be executed indirectly by the python interpreter, not directly in a CMake COMMAND. This is for portability reasons. Directly executing a python script depends on non-portable shebang logic and/or "default application" behaviour. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-06-21 14:34:42 +02:00
${PYTHON_EXECUTABLE}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
${PROCESS_PRIV_STACKS_GPERF}
-i ${PRIV_STACKS_OUTPUT_SRC_PRE}
-o ${PRIV_STACKS_OUTPUT_SRC}
-p "struct _k_priv_stack_map"
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
makefile: Fix dependencies for privileged stacks This patch fixes the dependency chain for priviliged stack generation. This fixes a problem when compiling after making significant changes that would shift the privileged stack area. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-05-01 08:10:26 +02:00
DEPENDS priv_stacks_output_src_pre ${PRIV_STACKS_OUTPUT_SRC_PRE}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(priv_stacks_output_src DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC})
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC}
PROPERTIES COMPILE_DEFINITIONS "${compile_definitions_interface}")
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC}
PROPERTIES COMPILE_FLAGS
userspace: don't modify optimization options The gperf hashtables and support functions are created after the initial zephyr_prebuilt.elf is created, using data found within it. A fixed-sized amount of memory is reserved for the program text of these support functions, as their true size isn't possible to predict in advance and we don't want memory addresses after them to shift. To minimize the amount of space reserved, it seemed reasonable to hard-code -Os. However, on ARC, building with -Os can cause various millicode functions from libgcc to be included in the binary which would not be present in zephyr_prebuilt.elf unless zephyr_prebuilt.elf was also built with -Os, causing anything after them to be shifted, wreaking all kinds of havoc. Just build without hardcoding any optimization parameters. We have checks in the linker scripts to let us know if we have overflowed the region for the gperf support functions anyway, so there is no danger of this failing silently. Fixes: #14139 Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-03-15 01:04:11 +01:00
"${NO_COVERAGE_FLAGS} -fno-function-sections -fno-data-sections ")
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
# We need precise control of where generated text/data ends up in the final
# kernel image. Disable function/data sections and use objcopy to move
# generated data into special section names
add_library(priv_stacks_output_lib STATIC
${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_SRC}
)
# Turn off -ffunction-sections, etc.
# NB: Using a library instead of target_compile_options(priv_stacks_output_lib
# [...]) because a library's options have precedence
add_library(priv_stacks_output_lib_interface INTERFACE)
cmake: Fix how we set include dirs for userspace To ensure the proper flags are specified to the toolchain, we need to keep system headers and non-system headers seperate and set the SYSTEM flag to target_include_directories for system headers. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-03-14 17:50:08 +01:00
foreach(incl ${include_dir_in_interface})
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
target_include_directories(priv_stacks_output_lib_interface INTERFACE ${incl})
endforeach()
cmake: Fix how we set include dirs for userspace To ensure the proper flags are specified to the toolchain, we need to keep system headers and non-system headers seperate and set the SYSTEM flag to target_include_directories for system headers. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-03-14 17:50:08 +01:00
foreach(incl ${sys_include_dir_in_interface})
target_include_directories(priv_stacks_output_lib_interface SYSTEM INTERFACE ${incl})
endforeach()
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
target_link_libraries(priv_stacks_output_lib priv_stacks_output_lib_interface)
set(PRIV_STACKS_OUTPUT_OBJ_PATH ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/priv_stacks_output_lib.dir/${PRIV_STACKS_OUTPUT_OBJ})
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
set(obj_copy_cmd "")
set(obj_copy_sections_rename
.bss=.priv_stacks.noinit
.data=.priv_stacks.data
.text=.priv_stacks.text
.rodata=.priv_stacks.rodata
)
bintools_objcopy(
RESULT_CMD_LIST obj_copy_cmd
SECTION_RENAME ${obj_copy_sections_rename}
FILE_INPUT ${PRIV_STACKS_OUTPUT_OBJ_PATH}
FILE_OUTPUT ${PRIV_STACKS_OUTPUT_OBJ_RENAMED}
)
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_OBJ_RENAMED}
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
${obj_copy_cmd}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
DEPENDS priv_stacks_output_lib
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(priv_stacks_output_obj_renamed DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_OBJ_RENAMED})
add_library(priv_stacks_output_obj_renamed_lib STATIC IMPORTED GLOBAL)
set_property(
TARGET priv_stacks_output_obj_renamed_lib
PROPERTY
IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${PRIV_STACKS_OUTPUT_OBJ_RENAMED}
)
add_dependencies(
priv_stacks_output_obj_renamed_lib
priv_stacks_output_obj_renamed
)
set_property(GLOBAL APPEND PROPERTY GENERATED_KERNEL_OBJECT_FILES priv_stacks_output_obj_renamed_lib)
endif()
gen_kobject_list.py: better comments and --help. Zero code change. - The script can but does not always generate five files, in fact the current build invokes it at least three times requesting different outputs every time. - --kobj-types-output produces a code fragment; not a standalone/usable header file. It outputs enum constants for a single enum type and not several enum types. - Some outputs include driver instances and others not: clarify which. - There's an entire and great section in the documentation that took me ages to find because it's not referenced anywhere in the --help or code. Fixed. - Highlight the massive duplication in the CMakeLists.txt to save déjà vu confusion and minimize future divergence. - Other minor tweaks. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-17 00:39:45 +02:00
# Warning: most of this gperf code is duplicated above for
# gen_priv_stacks.py / priv_stacks_output_lib
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(CONFIG_USERSPACE)
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
set(GEN_KOBJ_LIST ${ZEPHYR_BASE}/scripts/gen_kobject_list.py)
set(PROCESS_GPERF ${ZEPHYR_BASE}/scripts/process_gperf.py)
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(OBJ_LIST kobject_hash.gperf)
set(OUTPUT_SRC_PRE kobject_hash_preprocessed.c)
set(OUTPUT_SRC kobject_hash.c)
set(OUTPUT_OBJ kobject_hash.c.obj)
set(OUTPUT_OBJ_RENAMED kobject_hash_renamed.o)
# Essentially what we are doing here is extracting some information
# out of the nearly finished elf file, generating the source code
# for a hash table based on that information, and then compiling and
# linking the hash table back into a now even more nearly finished
gen_kobject_list.py: better comments and --help. Zero code change. - The script can but does not always generate five files, in fact the current build invokes it at least three times requesting different outputs every time. - --kobj-types-output produces a code fragment; not a standalone/usable header file. It outputs enum constants for a single enum type and not several enum types. - Some outputs include driver instances and others not: clarify which. - There's an entire and great section in the documentation that took me ages to find because it's not referenced anywhere in the --help or code. Fixed. - Highlight the massive duplication in the CMakeLists.txt to save déjà vu confusion and minimize future divergence. - Other minor tweaks. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-17 00:39:45 +02:00
# elf file. More information in gen_kobject_list.py --help.
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
# Use the script GEN_KOBJ_LIST to scan the kernel binary's
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
# (${ZEPHYR_PREBUILT_EXECUTABLE}) DWARF information to produce a table of kernel
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
# objects (OBJ_LIST) which we will then pass to gperf
add_custom_command(
OUTPUT ${OBJ_LIST}
COMMAND
${PYTHON_EXECUTABLE}
${GEN_KOBJ_LIST}
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
--kernel $<TARGET_FILE:${ZEPHYR_PREBUILT_EXECUTABLE}>
drivers: Perform a runtime check if a driver is capable of an operation Driver APIs might not implement all operations, making it possible for a user thread to get the kernel to execute a function at 0x00000000. Perform runtime checks in all the driver handlers, checking if they're capable of performing the requested operation. Fixes #6907. Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
2018-04-04 22:50:32 +02:00
--gperf-output ${OBJ_LIST}
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
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
DEPENDS ${ZEPHYR_PREBUILT_EXECUTABLE}
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
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(obj_list DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${OBJ_LIST})
# Use gperf to generate C code (OUTPUT_SRC_PRE) which implements a
# perfect hashtable based on OBJ_LIST
add_custom_command(
OUTPUT ${OUTPUT_SRC_PRE}
COMMAND
${GPERF}
--output-file ${OUTPUT_SRC_PRE}
${OBJ_LIST}
cmake: Fix dependencies between kobject_hash files CMake's custom_command support is not great. It is technically supported, but it is not easy to get it right. As explained in "5. File-level dependencies of custom targets are not propagated" from http://bit.ly/2GvwwEy. When a custom_command uses a custom_target as input, the custom_command must DEPEND on both the custom_target and the underlying file. Longterm we need to do something more sofisticated to prevent these issues from popping up. Like add some static analysis to detect badly written CMake code or introduce an abstraction for custom commands that is not affect by this issue. This fixes #5881 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-31 10:42:46 +01:00
DEPENDS obj_list ${OBJ_LIST}
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
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(output_src_pre DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_SRC_PRE})
# For our purposes the code/data generated by gperf is not optimal.
#
# The script PROCESS_GPERF creates a new c file OUTPUT_SRC based on
# OUTPUT_SRC_PRE to greatly reduce the amount of code/data generated
# since we know we are always working with pointer values
add_custom_command(
OUTPUT ${OUTPUT_SRC}
COMMAND
cmake: Invoke 'python' instead of py scripts directly Python scripts should be executed indirectly by the python interpreter, not directly in a CMake COMMAND. This is for portability reasons. Directly executing a python script depends on non-portable shebang logic and/or "default application" behaviour. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-06-21 14:34:42 +02:00
${PYTHON_EXECUTABLE}
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
${PROCESS_GPERF}
-i ${OUTPUT_SRC_PRE}
-o ${OUTPUT_SRC}
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
-p "struct _k_object"
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
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
cmake: Fix dependencies between kobject_hash files CMake's custom_command support is not great. It is technically supported, but it is not easy to get it right. As explained in "5. File-level dependencies of custom targets are not propagated" from http://bit.ly/2GvwwEy. When a custom_command uses a custom_target as input, the custom_command must DEPEND on both the custom_target and the underlying file. Longterm we need to do something more sofisticated to prevent these issues from popping up. Like add some static analysis to detect badly written CMake code or introduce an abstraction for custom commands that is not affect by this issue. This fixes #5881 Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-01-31 10:42:46 +01:00
DEPENDS output_src_pre ${OUTPUT_SRC_PRE}
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
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(output_src DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_SRC})
# We need precise control of where generated text/data ends up in the final
# kernel image. Disable function/data sections and use objcopy to move
# generated data into special section names
add_library(output_lib STATIC
${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_SRC}
)
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
set_source_files_properties(${OUTPUT_SRC} PROPERTIES COMPILE_FLAGS
userspace: don't modify optimization options The gperf hashtables and support functions are created after the initial zephyr_prebuilt.elf is created, using data found within it. A fixed-sized amount of memory is reserved for the program text of these support functions, as their true size isn't possible to predict in advance and we don't want memory addresses after them to shift. To minimize the amount of space reserved, it seemed reasonable to hard-code -Os. However, on ARC, building with -Os can cause various millicode functions from libgcc to be included in the binary which would not be present in zephyr_prebuilt.elf unless zephyr_prebuilt.elf was also built with -Os, causing anything after them to be shifted, wreaking all kinds of havoc. Just build without hardcoding any optimization parameters. We have checks in the linker scripts to let us know if we have overflowed the region for the gperf support functions anyway, so there is no danger of this failing silently. Fixes: #14139 Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-03-15 01:04:11 +01:00
"${NO_COVERAGE_FLAGS} -fno-function-sections -fno-data-sections")
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
set_source_files_properties(${OUTPUT_SRC}
PROPERTIES COMPILE_DEFINITIONS "${compile_definitions_interface}")
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
# Turn off -ffunction-sections, etc.
# NB: Using a library instead of target_compile_options(output_lib
# [...]) because a library's options have precedence
add_library(output_lib_interface INTERFACE)
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01: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
target_link_libraries(output_lib output_lib_interface)
cmake: Fix how we set include dirs for userspace To ensure the proper flags are specified to the toolchain, we need to keep system headers and non-system headers seperate and set the SYSTEM flag to target_include_directories for system headers. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-03-14 17:50:08 +01:00
foreach(incl ${include_dir_in_interface})
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01:00
target_include_directories(output_lib_interface INTERFACE ${incl})
endforeach()
cmake: Fix how we set include dirs for userspace To ensure the proper flags are specified to the toolchain, we need to keep system headers and non-system headers seperate and set the SYSTEM flag to target_include_directories for system headers. Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
2019-03-14 17:50:08 +01:00
foreach(incl ${sys_include_dir_in_interface})
target_include_directories(output_lib_interface SYSTEM INTERFACE ${incl})
endforeach()
cmake: Generated files are excluded from coverage. When coverage option is enabled, all C files will have coverage option enabled. When we enable it for generated files it adds extra .bss info and other related information. Since the bss has now increased the perfect hash that was calculated by gperf is now incorrect. Which is a problem for userspace enabled systems. This patch will make sure that the generated C files will be compiled without the coverage flags. The remaining functionality remains unchanged. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
2018-11-21 10:01:56 +01: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(OUTPUT_OBJ_PATH ${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/output_lib.dir/${OUTPUT_OBJ})
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
set(obj_copy_cmd "")
set(obj_copy_sections_rename
.data=.kobject_data.data
.text=.kobject_data.text
.rodata=.kobject_data.rodata
)
bintools_objcopy(
RESULT_CMD_LIST obj_copy_cmd
SECTION_RENAME ${obj_copy_sections_rename}
FILE_INPUT ${OUTPUT_OBJ_PATH}
FILE_OUTPUT ${OUTPUT_OBJ_RENAMED}
)
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
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_OBJ_RENAMED}
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
${obj_copy_cmd}
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
DEPENDS output_lib
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
)
add_custom_target(output_obj_renamed DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_OBJ_RENAMED})
add_library(output_obj_renamed_lib STATIC IMPORTED GLOBAL)
set_property(
TARGET output_obj_renamed_lib
PROPERTY
IMPORTED_LOCATION ${CMAKE_CURRENT_BINARY_DIR}/${OUTPUT_OBJ_RENAMED}
)
add_dependencies(
output_obj_renamed_lib
output_obj_renamed
)
set_property(GLOBAL APPEND PROPERTY GENERATED_KERNEL_OBJECT_FILES output_obj_renamed_lib)
endif()
# Read global variables into local variables
get_property(GKOF GLOBAL PROPERTY GENERATED_KERNEL_OBJECT_FILES)
get_property(GKSF GLOBAL PROPERTY GENERATED_KERNEL_SOURCE_FILES)
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
cmake: Allow C standard version to be overriden Allow archs/boards/apps to override the C standard version. Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2018-07-05 10:51:03 +02:00
get_property(CSTD GLOBAL PROPERTY CSTD)
set_ifndef(CSTD c99)
cmake: Toolchain abstraction: Introducing macro toolchain_cc_cstd_flag The macro obtains the toolchain specific flag and value for setting of the requested c standard. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-06-13 15:33:03 +02:00
# @Intent: Obtain compiler specific flag for specifying the c standard
toolchain_cc_cstd_flag(CC_CSTD ${CSTD})
cmake: Allow C standard version to be overriden Allow archs/boards/apps to override the C standard version. Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2018-07-05 10:51:03 +02:00
zephyr_compile_options(
cmake: Toolchain abstraction: Introducing macro toolchain_cc_cstd_flag The macro obtains the toolchain specific flag and value for setting of the requested c standard. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-06-13 15:33:03 +02:00
$<$<COMPILE_LANGUAGE:C>:${CC_CSTD}>
cmake: Allow C standard version to be overriden Allow archs/boards/apps to override the C standard version. Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2018-07-05 10:51:03 +02:00
)
cmake: Toolchain abstraction: Introduce toolchain_ld_configure_files No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-03 11:02:56 +02:00
# @Intent: Configure linker scripts, i.e. generate linker scripts with variables substituted
toolchain_ld_configure_files()
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
userspace: remove APP_SHARED_MEM Kconfig This is an integral part of userspace and cannot be used on its own. Fold into the main userspace configuration. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-23 01:08:44 +01:00
if(CONFIG_USERSPACE)
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
set(APP_SMEM_ALIGNED_LD "${PROJECT_BINARY_DIR}/include/generated/app_smem_aligned.ld")
set(APP_SMEM_UNALIGNED_LD "${PROJECT_BINARY_DIR}/include/generated/app_smem_unaligned.ld")
app_shmem: use script for all arches This patch will run the python scripts for all architectures to determine the partitions available. This is needed for correct operation of the app_shared_mem feature. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com> Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-20 11:17:42 +01:00
set(OBJ_FILE_DIR "${PROJECT_BINARY_DIR}/../")
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
app_shmem: use script for all arches This patch will run the python scripts for all architectures to determine the partitions available. This is needed for correct operation of the app_shared_mem feature. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com> Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-20 11:17:42 +01:00
add_custom_target(
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
${APP_SMEM_ALIGNED_DEP}
DEPENDS
${APP_SMEM_ALIGNED_LD}
)
add_custom_target(
${APP_SMEM_UNALIGNED_DEP}
cmake: Fix dependencies for LD script generation The dependencies relating to generating LD scripts are declared incorrectly. This manifests itself as broken incremental builds as shown in #13001. This commit aligns the LD script generation with the Zephyr standard for declaring custom commands. For instance, custom commands should generate files that are wrapped by targets. The custom commands should declare the dependencies, not the targets. Also, when using custom commands, the OUTPUT signature should be used, not the TARGET signature, as app_smem was doing. For details about how Zephyr uses custom commands see https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ This fixes #13001. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:49:57 +01:00
DEPENDS
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
${APP_SMEM_UNALIGNED_LD}
app_shmem: use script for all arches This patch will run the python scripts for all architectures to determine the partitions available. This is needed for correct operation of the app_shared_mem feature. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com> Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-20 11:17:42 +01:00
)
userspace: compartmentalized app memory organization Summary: revised attempt at addressing issue 6290. The following provides an alternative to using CONFIG_APPLICATION_MEMORY by compartmentalizing data into Memory Domains. Dependent on MPU limitations, supports compartmentalized Memory Domains for 1...N logical applications. This is considered an initial attempt at designing flexible compartmentalized Memory Domains for multiple logical applications and, with the provided python script and edited CMakeLists.txt, provides support for power of 2 aligned MPU architectures. Overview: The current patch uses qualifiers to group data into subsections. The qualifier usage allows for dynamic subsection creation and affords the developer a large amount of flexibility in the grouping, naming, and size of the resulting partitions and domains that are built on these subsections. By additional macro calls, functions are created that help calculate the size, address, and permissions for the subsections and enable the developer to control application data in specified partitions and memory domains. Background: Initial attempts focused on creating a single section in the linker script that then contained internally grouped variables/data to allow MPU/MMU alignment and protection. This did not provide additional functionality beyond CONFIG_APPLICATION_MEMORY as we were unable to reliably group data or determine their grouping via exported linker symbols. Thus, the resulting decision was made to dynamically create subsections using the current qualifier method. An attempt to group the data by object file was tested, but found that this broke applications such as ztest where two object files are created: ztest and main. This also creates an issue of grouping the two object files together in the same memory domain while also allowing for compartmenting other data among threads. Because it is not possible to know a) the name of the partition and thus the symbol in the linker, b) the size of all the data in the subsection, nor c) the overall number of partitions created by the developer, it was not feasible to align the subsections at compile time without using dynamically generated linker script for MPU architectures requiring power of 2 alignment. In order to provide support for MPU architectures that require a power of 2 alignment, a python script is run at build prior to when linker_priv_stacks.cmd is generated. This script scans the built object files for all possible partitions and the names given to them. It then generates a linker file (app_smem.ld) that is included in the main linker.ld file. This app_smem.ld allows the compiler and linker to then create each subsection and align to the next power of 2. Usage: - Requires: app_memory/app_memdomain.h . - _app_dmem(id) marks a variable to be placed into a data section for memory partition id. - _app_bmem(id) marks a variable to be placed into a bss section for memory partition id. - These are seen in the linker.map as "data_smem_id" and "data_smem_idb". - To create a k_mem_partition, call the macro app_mem_partition(part0) where "part0" is the name then used to refer to that partition. This macro only creates a function and necessary data structures for the later "initialization". - To create a memory domain for the partition, the macro app_mem_domain(dom0) is called where "dom0" is the name then used for the memory domain. - To initialize the partition (effectively adding the partition to a linked list), init_part_part0() is called. This is followed by init_app_memory(), which walks all partitions in the linked list and calculates the sizes for each partition. - Once the partition is initialized, the domain can be initialized with init_domain_dom0(part0) which initializes the domain with partition part0. - After the domain has been initialized, the current thread can be added using add_thread_dom0(k_current_get()). - The code used in ztests ans kernel/init has been added under a conditional #ifdef to isolate the code from other tests. The userspace test CMakeLists.txt file has commands to insert the CONFIG_APP_SHARED_MEM definition into the required build targets. Example: /* create partition at top of file outside functions */ app_mem_partition(part0); /* create domain */ app_mem_domain(dom0); _app_dmem(dom0) int var1; _app_bmem(dom0) static volatile int var2; int main() { init_part_part0(); init_app_memory(); init_domain_dom0(part0); add_thread_dom0(k_current_get()); ... } - If multiple partitions are being created, a variadic preprocessor macro can be used as provided in app_macro_support.h: FOR_EACH(app_mem_partition, part0, part1, part2); or, for multiple domains, similarly: FOR_EACH(app_mem_domain, dom0, dom1); Similarly, the init_part_* can also be used in the macro: FOR_EACH(init_part, part0, part1, part2); Testing: - This has been successfully tested on qemu_x86 and the ARM frdm_k64f board. It compiles and builds power of 2 aligned subsections for the linker script on the 96b_carbon boards. These power of 2 alignments have been checked by hand and are viewable in the zephyr.map file that is produced during build. However, due to a shortage of available MPU regions on the 96b_carbon board, we are unable to test this. - When run on the 96b_carbon board, the test suite will enter execution, but each individaul test will fail due to an MPU FAULT. This is expected as the required number of MPU regions exceeds the number allowed due to the static allocation. As the MPU driver does not detect this issue, the fault occurs because the data being accessed has been placed outside the active MPU region. - This now compiles successfully for the ARC boards em_starterkit_em7d and em_starterkit_em7d_v22. However, as we lack ARC hardware to run this build on, we are unable to test this build. Current known issues: 1) While the script and edited CMakeLists.txt creates the ability to align to the next power of 2, this does not address the shortage of available MPU regions on certain devices (e.g. 96b_carbon). In testing the APB and PPB regions were commented out. 2) checkpatch.pl lists several issues regarding the following: a) Complex macros. The FOR_EACH macros as defined in app_macro_support.h are listed as complex macros needing parentheses. Adding parentheses breaks their functionality, and we have otherwise been unable to resolve the reported error. b) __aligned() preferred. The _app_dmem_pad() and _app_bmem_pad() macros give warnings that __aligned() is preferred. Prior iterations had this implementation, which resulted in errors due to "complex macros". c) Trailing semicolon. The macro init_part(name) has a trailing semicolon as the semicolon is needed for the inlined macro call that is generated when this macro expands. Update: updated to alternative CONFIG_APPLCATION_MEMORY. Added config option CONFIG_APP_SHARED_MEM to enable a new section app_smem to contain the shared memory component. This commit seperates the Kconfig definition from the definition used for the conditional code. The change is in response to changes in the way the build system treats definitions. The python script used to generate a linker script for app_smem was also midified to simplify the alignment directives. A default linker script app_smem.ld was added to remove the conditional includes dependency on CONFIG_APP_SHARED_MEM. By addining the default linker script the prebuild stages link properly prior to the python script running Signed-off-by: Joshua Domagalski <jedomag@tycho.nsa.gov> Signed-off-by: Shawn Mosley <smmosle@tycho.nsa.gov>
2018-04-26 16:14:02 +02:00
libc: set up memory partitions * Newlib now defines a special z_newlib_partition containing all globals relevant to newlib. Most of these are in libc.a with a heap tracking variable in newlib's hooks. * Both C libraries now expose a k_mem_partition containing the bounds of the malloc heap arena. Threads that want to use libc malloc() will need to add this to their memory domain. * z_newlib_get_heap_bounds has been removed, in favor of the memory partition for the heap arena * ztest now includes the C library partitions in its memory domain. * The mem_alloc test now runs in user mode to prove that this all works for both C libraries. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-01 21:18:31 +01:00
if(CONFIG_NEWLIB_LIBC)
app_shmem: create generic libc partition We need a generic name for the partition containing essential C library globals. We're going to need to add the stack canary guard to this area so user mode can read it. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-21 22:44:54 +01:00
set(NEWLIB_PART -l libc.a z_libc_partition)
libc: set up memory partitions * Newlib now defines a special z_newlib_partition containing all globals relevant to newlib. Most of these are in libc.a with a heap tracking variable in newlib's hooks. * Both C libraries now expose a k_mem_partition containing the bounds of the malloc heap arena. Threads that want to use libc malloc() will need to add this to their memory domain. * z_newlib_get_heap_bounds has been removed, in favor of the memory partition for the heap arena * ztest now includes the C library partitions in its memory domain. * The mem_alloc test now runs in user mode to prove that this all works for both C libraries. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-01 21:18:31 +01:00
endif()
mbedtls: provide user mode access The mbedtls library has some globals which results in faults when user mode tries to access them. Instantiate a memory partition for mbedtls's globals. The linker will place all globals found by building this library into this partition. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-27 23:41:45 +01:00
if(CONFIG_MBEDTLS)
mbedtls: move to external module Use external module from https://github.com/zephyrproject-rtos/mbedtls Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2019-05-09 14:43:30 +02:00
set(MBEDTLS_PART -l lib..__modules__crypto__mbedtls.a k_mbedtls_partition)
mbedtls: provide user mode access The mbedtls library has some globals which results in faults when user mode tries to access them. Instantiate a memory partition for mbedtls's globals. The linker will place all globals found by building this library into this partition. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-27 23:41:45 +01:00
endif()
app_shmem: use script for all arches This patch will run the python scripts for all architectures to determine the partitions available. This is needed for correct operation of the app_shared_mem feature. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com> Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-20 11:17:42 +01:00
add_custom_command(
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
OUTPUT ${APP_SMEM_UNALIGNED_LD}
app_shmem: use script for all arches This patch will run the python scripts for all architectures to determine the partitions available. This is needed for correct operation of the app_shared_mem feature. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com> Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-20 11:17:42 +01:00
COMMAND ${PYTHON_EXECUTABLE}
${ZEPHYR_BASE}/scripts/gen_app_partitions.py
-d ${OBJ_FILE_DIR}
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
-o ${APP_SMEM_UNALIGNED_LD}
${NEWLIB_PART} ${MBEDTLS_PART}
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
DEPENDS
kernel
${ZEPHYR_LIBS_PROPERTY}
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/
COMMENT "Generating app_smem_unaligned linker section"
)
cmake: rename construct_add_custom_command_for_linker_pass macro Now that we avoid the two-step procedure, we can simplify the name of the construct_add_custom_command_for_linker_pass macro. Move description comment up to head of definition, making the purpose clearer. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 17:16:54 +02:00
configure_linker_script(
cmake: configure_linker_script: accept argument with file extension Reduce the amount of {pre,post}fixing magic: I.e. let it be clearer at call sites that "linker.cmd" is a file, rather than having to know that "linker" will be postfixed with ".cmd" internally. Change argument name to linker_script_gen, to better indicate that we are producing a generated file. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 20:27:23 +02:00
linker_app_smem_unaligned.cmd
cmake: simplify configure_linker_script: avoid deriving define from name Rather than associating defines within the function, let the call sites themselves pick the appropriate define. Add new argument for this. This also permits us to remove regex matching. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 20:35:12 +02:00
"-DLINKER_APP_SMEM_UNALIGNED"
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
${CODE_RELOCATION_DEP}
${APP_SMEM_UNALIGNED_DEP}
${APP_SMEM_UNALIGNED_LD}
${OFFSETS_H_TARGET}
)
add_custom_target(
linker_app_smem_unaligned_script
DEPENDS
linker_app_smem_unaligned.cmd
)
set_property(TARGET
linker_app_smem_unaligned_script
PROPERTY INCLUDE_DIRECTORIES
${ZEPHYR_INCLUDE_DIRS}
)
set(APP_SMEM_UNALIGNED_LIB app_smem_unaligned_output_obj_renamed_lib)
add_executable( app_smem_unaligned_prebuilt misc/empty_file.c)
cmake: Introduce toolchain_ld_link_elf to abstract linker invocation Final step of linker abstraction: * Abstract zephyr_lnk by including it in toolchain_ld_link_elf. * Abstract relevant uses of target_link_libraries. * Introduce toolchain_ld_force_undefined_symbols. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 16:32:36 +02:00
toolchain_ld_link_elf(
TARGET_ELF app_smem_unaligned_prebuilt
cmake: stop destroying intermediate link maps like zephyr_prebuilt.map The different linker steps are all hardcoded to the output filename "zephyr.map" and only the last one survives. Un-harcode. This removes some confusion when trying to follow who builds what/when/how and it stops destroying intermediate linking information useful when tracing/debugging new features or issues in the build. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-14 01:15:44 +02:00
OUTPUT_MAP ${PROJECT_BINARY_DIR}/app_smem_unaligned_prebuilt.map
cmake: Introduce toolchain_ld_link_elf to abstract linker invocation Final step of linker abstraction: * Abstract zephyr_lnk by including it in toolchain_ld_link_elf. * Abstract relevant uses of target_link_libraries. * Introduce toolchain_ld_force_undefined_symbols. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 16:32:36 +02:00
LIBRARIES_PRE_SCRIPT ""
LINKER_SCRIPT ${PROJECT_BINARY_DIR}/linker_app_smem_unaligned.cmd
LIBRARIES_POST_SCRIPT ""
DEPENDENCIES ${CODE_RELOCATION_DEP}
)
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
set_property(TARGET app_smem_unaligned_prebuilt PROPERTY LINK_DEPENDS ${PROJECT_BINARY_DIR}/linker_app_smem_unaligned.cmd)
cmake: remove unused ALIGN_SIZING_DEP Full grep reveal ALIGN_SIZING_DEP is only mentioned in cmake, where it is never assigned a value. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 14:49:33 +02:00
add_dependencies( app_smem_unaligned_prebuilt linker_app_smem_unaligned_script ${OFFSETS_LIB})
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
add_custom_command(
OUTPUT ${APP_SMEM_ALIGNED_LD}
COMMAND ${PYTHON_EXECUTABLE}
${ZEPHYR_BASE}/scripts/gen_app_partitions.py
-e $<TARGET_FILE:app_smem_unaligned_prebuilt>
-o ${APP_SMEM_ALIGNED_LD}
mbedtls: provide user mode access The mbedtls library has some globals which results in faults when user mode tries to access them. Instantiate a memory partition for mbedtls's globals. The linker will place all globals found by building this library into this partition. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-27 23:41:45 +01:00
${NEWLIB_PART} ${MBEDTLS_PART}
app_shmem: use script for all arches This patch will run the python scripts for all architectures to determine the partitions available. This is needed for correct operation of the app_shared_mem feature. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com> Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-20 11:17:42 +01:00
$<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
cmake: Fix dependencies for LD script generation The dependencies relating to generating LD scripts are declared incorrectly. This manifests itself as broken incremental builds as shown in #13001. This commit aligns the LD script generation with the Zephyr standard for declaring custom commands. For instance, custom commands should generate files that are wrapped by targets. The custom commands should declare the dependencies, not the targets. Also, when using custom commands, the OUTPUT signature should be used, not the TARGET signature, as app_smem was doing. For details about how Zephyr uses custom commands see https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ This fixes #13001. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:49:57 +01:00
DEPENDS
kernel
${ZEPHYR_LIBS_PROPERTY}
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
app_smem_unaligned_prebuilt
app_shmem: use script for all arches This patch will run the python scripts for all architectures to determine the partitions available. This is needed for correct operation of the app_shared_mem feature. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com> Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-20 11:17:42 +01:00
WORKING_DIRECTORY ${PROJECT_BINARY_DIR}/
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
COMMENT "Generating app_smem_aligned linker section"
app_shmem: use script for all arches This patch will run the python scripts for all architectures to determine the partitions available. This is needed for correct operation of the app_shared_mem feature. Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com> Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-12-20 11:17:42 +01:00
)
endif()
userspace: remove APPLICATION_MEMORY feature This was never a long-term solution, more of a gross hack to get test cases working until we could figure out a good end-to-end solution for memory domains that generated appropriate linker sections. Now that we have this with the app shared memory feature, and have converted all tests to remove it, delete this feature. To date all userspace APIs have been tagged as 'experimental' which sidesteps deprecation policies. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2019-02-01 00:53:24 +01:00
if(CONFIG_USERSPACE AND CONFIG_ARM)
cmake: rename construct_add_custom_command_for_linker_pass macro Now that we avoid the two-step procedure, we can simplify the name of the construct_add_custom_command_for_linker_pass macro. Move description comment up to head of definition, making the purpose clearer. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 17:16:54 +02:00
configure_linker_script(
cmake: configure_linker_script: accept argument with file extension Reduce the amount of {pre,post}fixing magic: I.e. let it be clearer at call sites that "linker.cmd" is a file, rather than having to know that "linker" will be postfixed with ".cmd" internally. Change argument name to linker_script_gen, to better indicate that we are producing a generated file. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 20:27:23 +02:00
linker_priv_stacks.cmd
cmake: simplify configure_linker_script: avoid deriving define from name Rather than associating defines within the function, let the call sites themselves pick the appropriate define. Add new argument for this. This also permits us to remove regex matching. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 20:35:12 +02:00
""
cmake: Fix dependencies for LD script generation The dependencies relating to generating LD scripts are declared incorrectly. This manifests itself as broken incremental builds as shown in #13001. This commit aligns the LD script generation with the Zephyr standard for declaring custom commands. For instance, custom commands should generate files that are wrapped by targets. The custom commands should declare the dependencies, not the targets. Also, when using custom commands, the OUTPUT signature should be used, not the TARGET signature, as app_smem was doing. For details about how Zephyr uses custom commands see https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ This fixes #13001. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:49:57 +01:00
${CODE_RELOCATION_DEP}
linker: sort app shared mem partition by alignment If CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT is enabled, the app shared memory partition may cause waste of memory due to the need for padding. For example, tests/subsys/jwt and board mps2_an385: z_test_mem_partition: addr 0x20000000, size 52 z_libc_partition : addr 0x20000040, size 4 k_mbedtls_partition : addr 0x20008000, size 32736 ending at 0x2000ffff, taking up 65536 bytes With power-of-two size and alignment requirement, k_mbedtls_partition takes up 32KB memory and needs to be aligned on 32KB boundary. If the above partitions are ordered as shown, there needs to be a lot of padding after z_libc_partition before k_mbedtls_partition can start. In order to minimize padding, these partitions need to be sort by size in descending order. After the changes here, the partitions are: k_mbedtls_partition : addr 0x20000000, size 32736 z_test_mem_partition: addr 0x20008000, size 52 z_libc_partition : addr 0x20008040, size 4 ending at 0x2000805f, taking up 32864 bytes With the above example, sorting results in a saving of 32672 bytes of saving. Fixes #14121 Signed-off-by: Daniel Leung <daniel.leung@intel.com>
2019-03-10 22:20:21 +01:00
${APP_SMEM_ALIGNED_DEP}
${APP_SMEM_ALIGNED_LD}
cmake: Fix dependencies for LD script generation The dependencies relating to generating LD scripts are declared incorrectly. This manifests itself as broken incremental builds as shown in #13001. This commit aligns the LD script generation with the Zephyr standard for declaring custom commands. For instance, custom commands should generate files that are wrapped by targets. The custom commands should declare the dependencies, not the targets. Also, when using custom commands, the OUTPUT signature should be used, not the TARGET signature, as app_smem was doing. For details about how Zephyr uses custom commands see https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ This fixes #13001. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:49:57 +01:00
${OFFSETS_H_TARGET}
cmake: Various refactorings and whitespace fixes This commit applies various refactorings and whitespace fixes in preparation for the patch that fixes #13001. It includes changing indentation from tabs to spaces and splitting tokens across more lines to increase readability and minimize patch sizes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:39:37 +01:00
)
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
add_custom_target(
linker_priv_stacks_script
DEPENDS
linker_priv_stacks.cmd
)
set_property(TARGET
linker_priv_stacks_script
PROPERTY INCLUDE_DIRECTORIES
${ZEPHYR_INCLUDE_DIRS}
)
set(PRIV_STACK_LIB priv_stacks_output_obj_renamed_lib)
add_executable( priv_stacks_prebuilt misc/empty_file.c)
cmake: Introduce toolchain_ld_link_elf to abstract linker invocation Final step of linker abstraction: * Abstract zephyr_lnk by including it in toolchain_ld_link_elf. * Abstract relevant uses of target_link_libraries. * Introduce toolchain_ld_force_undefined_symbols. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 16:32:36 +02:00
toolchain_ld_link_elf(
TARGET_ELF priv_stacks_prebuilt
cmake: stop destroying intermediate link maps like zephyr_prebuilt.map The different linker steps are all hardcoded to the output filename "zephyr.map" and only the last one survives. Un-harcode. This removes some confusion when trying to follow who builds what/when/how and it stops destroying intermediate linking information useful when tracing/debugging new features or issues in the build. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-14 01:15:44 +02:00
OUTPUT_MAP ${PROJECT_BINARY_DIR}/priv_stacks_prebuilt.map
cmake: Introduce toolchain_ld_link_elf to abstract linker invocation Final step of linker abstraction: * Abstract zephyr_lnk by including it in toolchain_ld_link_elf. * Abstract relevant uses of target_link_libraries. * Introduce toolchain_ld_force_undefined_symbols. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 16:32:36 +02:00
LIBRARIES_PRE_SCRIPT ""
LINKER_SCRIPT ${PROJECT_BINARY_DIR}/linker_priv_stacks.cmd
LIBRARIES_POST_SCRIPT ""
DEPENDENCIES ${CODE_RELOCATION_DEP}
)
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01:00
set_property(TARGET priv_stacks_prebuilt PROPERTY LINK_DEPENDS ${PROJECT_BINARY_DIR}/linker_priv_stacks.cmd)
cmake: remove unused ALIGN_SIZING_DEP Full grep reveal ALIGN_SIZING_DEP is only mentioned in cmake, where it is never assigned a value. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 14:49:33 +02:00
add_dependencies( priv_stacks_prebuilt linker_priv_stacks_script ${OFFSETS_LIB})
cmake: disable privilege stack generation for arc Currently, ARC will not use privilege stack generation. Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
2018-02-12 12:17:04 +01:00
endif()
arm: Generate privileged stacks This patch adds the generation and incorporation of privileged stack regions that are used by ARM user mode threads. This patch adds the infrastructure for privileged stacks. Later patches will utilize the generated stacks and helper functions. Signed-off-by: Chunlin Han <chunlin.han@linaro.org> Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:19:49 +01: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
# FIXME: Is there any way to get rid of empty_file.c?
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
add_executable( ${ZEPHYR_PREBUILT_EXECUTABLE} misc/empty_file.c)
cmake: Introduce toolchain_ld_link_elf to abstract linker invocation Final step of linker abstraction: * Abstract zephyr_lnk by including it in toolchain_ld_link_elf. * Abstract relevant uses of target_link_libraries. * Introduce toolchain_ld_force_undefined_symbols. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 16:32:36 +02:00
toolchain_ld_link_elf(
TARGET_ELF ${ZEPHYR_PREBUILT_EXECUTABLE}
cmake: stop destroying intermediate link maps like zephyr_prebuilt.map The different linker steps are all hardcoded to the output filename "zephyr.map" and only the last one survives. Un-harcode. This removes some confusion when trying to follow who builds what/when/how and it stops destroying intermediate linking information useful when tracing/debugging new features or issues in the build. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-14 01:15:44 +02:00
OUTPUT_MAP ${PROJECT_BINARY_DIR}/${ZEPHYR_PREBUILT_EXECUTABLE}.map
cmake: Introduce toolchain_ld_link_elf to abstract linker invocation Final step of linker abstraction: * Abstract zephyr_lnk by including it in toolchain_ld_link_elf. * Abstract relevant uses of target_link_libraries. * Introduce toolchain_ld_force_undefined_symbols. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 16:32:36 +02:00
LIBRARIES_PRE_SCRIPT ""
LINKER_SCRIPT ${PROJECT_BINARY_DIR}/linker.cmd
LIBRARIES_POST_SCRIPT ${PRIV_STACK_LIB}
DEPENDENCIES ${CODE_RELOCATION_DEP}
)
cmake: Use a variable for 'zephyr_prebuilt' There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:31:02 +01:00
set_property(TARGET ${ZEPHYR_PREBUILT_EXECUTABLE} PROPERTY LINK_DEPENDS ${PROJECT_BINARY_DIR}/linker.cmd)
cmake: remove unused ALIGN_SIZING_DEP Full grep reveal ALIGN_SIZING_DEP is only mentioned in cmake, where it is never assigned a value. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 14:49:33 +02:00
add_dependencies( ${ZEPHYR_PREBUILT_EXECUTABLE} ${PRIV_STACK_DEP} ${LINKER_SCRIPT_TARGET} ${OFFSETS_LIB})
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
arch: native: Run Zephyr natively in a POSIX OS A new arch (posix) which relies on pthreads to emulate the context switching A new soc for it (inf_clock) which emulates a CPU running at an infinely high clock (so when the CPU is awaken it runs till completion in 0 time) A new board, which provides a trivial system tick timer and irq generation. Origin: Original Fixes #1891 Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com> Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-10-03 16:31:55 +02:00
CMakeLists.txt: fix misleading logical_target_for_zephyr_elf comment The comment for: set_target_properties(${logical_target_for_zephyr_elf} PROPERTIES OUTPUT_NAME ${KERNEL_NAME}) was completely off-topic and making something relatively simple incredibly puzzling and time-consuming to understand. Re-order the if(GKSF OR GKOF) clauses so the two initializations of logical_target_for_zephyr_elf are close to each other and so the very short clause is not buried at the bottom of the long one. Other minor logical_target_for_zephyr_elf comment fixes. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-17 08:30:52 +02:00
set(generated_kernel_files ${GKSF} ${GKOF})
if(NOT generated_kernel_files)
# Use the prebuilt elf as the final elf since we don't have a
# generation stage.
set(logical_target_for_zephyr_elf ${ZEPHYR_PREBUILT_EXECUTABLE})
else()
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 second linker pass uses the same source linker script of the
cmake: ld: Refactor the linker script's cpp command construction Construct the custom command for preprocessing the linker script with a function to avoid copy-paste errors between linker passes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-31 10:39:23 +01:00
# first pass (LINKER_SCRIPT), but this time with a different output
# file and preprocessed with the define LINKER_PASS2.
cmake: rename construct_add_custom_command_for_linker_pass macro Now that we avoid the two-step procedure, we can simplify the name of the construct_add_custom_command_for_linker_pass macro. Move description comment up to head of definition, making the purpose clearer. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 17:16:54 +02:00
configure_linker_script(
cmake: configure_linker_script: accept argument with file extension Reduce the amount of {pre,post}fixing magic: I.e. let it be clearer at call sites that "linker.cmd" is a file, rather than having to know that "linker" will be postfixed with ".cmd" internally. Change argument name to linker_script_gen, to better indicate that we are producing a generated file. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 20:27:23 +02:00
linker_pass_final.cmd
cmake: simplify configure_linker_script: avoid deriving define from name Rather than associating defines within the function, let the call sites themselves pick the appropriate define. Add new argument for this. This also permits us to remove regex matching. No functional change expected. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-04-29 20:35:12 +02:00
"-DLINKER_PASS2"
cmake: Fix dependencies for LD script generation The dependencies relating to generating LD scripts are declared incorrectly. This manifests itself as broken incremental builds as shown in #13001. This commit aligns the LD script generation with the Zephyr standard for declaring custom commands. For instance, custom commands should generate files that are wrapped by targets. The custom commands should declare the dependencies, not the targets. Also, when using custom commands, the OUTPUT signature should be used, not the TARGET signature, as app_smem was doing. For details about how Zephyr uses custom commands see https://samthursfield.wordpress.com/2015/11/21/cmake-dependencies-between-targets-and-files-and-custom-commands/ This fixes #13001. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:49:57 +01:00
${PRIV_STACK_DEP}
${CODE_RELOCATION_DEP}
${ZEPHYR_PREBUILT_EXECUTABLE}
${OFFSETS_H_TARGET}
cmake: Various refactorings and whitespace fixes This commit applies various refactorings and whitespace fixes in preparation for the patch that fixes #13001. It includes changing indentation from tabs to spaces and splitting tokens across more lines to increase readability and minimize patch sizes. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-02-08 15:39:37 +01:00
)
arm: Add app data section alignment constraints This patch adds application data section alignment constraints to match the region definition requirements for ARM MPUs. Most MPUs require a minimum of 32 bytes of alignment for any regions, but some require power of two alignment to the size of a region. This requires that the linker align the application data section to the size of the section. This requires a linker pass to determine the size. Once this is accomplished the correct value is added to a linker include file that is utilized in subsequent linker operations. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-02-01 08:12:32 +01:00
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
set(LINKER_PASS_FINAL_SCRIPT_TARGET linker_pass_final_script_target)
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
add_custom_target(
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${LINKER_PASS_FINAL_SCRIPT_TARGET}
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
DEPENDS
makefile: Convert linker function to use names This patch changes the way the custom linker function works. It uses names instead of numbers to denote the name of the file and applies the correct LINKER_PASS variable for the final linker pass. Signed-off-by: Andy Gross <andy.gross@linaro.org>
2018-01-25 18:07:03 +01:00
linker_pass_final.cmd
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: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
set_property(TARGET
cmake: Use variables for target names There is an effort underway to make most of the Zephyr build script's reentrant. Meaning, the build scripts can be executed multiple times during the same CMake invocation. Reentrancy enables several use-cases, the motivating one is the ability to build several Zephyr executables, or images, for instance a bootloader and an application. For build scripts to be reentrant they cannot be directly referencing global variables, like target names, but must instead reference variables, which can vary from entry to entry. Therefore, in this patch, we replace global targets with variables. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-01-14 16:39:33 +01:00
${LINKER_PASS_FINAL_SCRIPT_TARGET}
cmake: ld: Ensure that a linker script change triggers a rebuild This fixes https://github.com/zephyrproject-rtos/zephyr/issues/5010. CMake has a simple parser that can parse C-like files to find header dependencies. But the parser needs to know what the include directories are to be able to follow #include pragmas. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2017-12-14 13:03:23 +01:00
PROPERTY INCLUDE_DIRECTORIES
${ZEPHYR_INCLUDE_DIRS}
)
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: Rename kernel_elf to zephyr_final * KERNEL_ELF was easily confused with KERNEL_ELF_NAME and KERNEL_NAME. * kernel_elf as the name of the binary indicates it somehow only contains the kernel, which is not correct. Rename to zephyr_final as this is the reality: Zephyr elf has been linked again (a number of times) due to generated kernel files. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 15:20:20 +02:00
add_executable( ${ZEPHYR_FINAL_EXECUTABLE} misc/empty_file.c ${GKSF})
cmake: Introduce toolchain_ld_link_elf to abstract linker invocation Final step of linker abstraction: * Abstract zephyr_lnk by including it in toolchain_ld_link_elf. * Abstract relevant uses of target_link_libraries. * Introduce toolchain_ld_force_undefined_symbols. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 16:32:36 +02:00
toolchain_ld_link_elf(
TARGET_ELF ${ZEPHYR_FINAL_EXECUTABLE}
cmake: stop destroying intermediate link maps like zephyr_prebuilt.map The different linker steps are all hardcoded to the output filename "zephyr.map" and only the last one survives. Un-harcode. This removes some confusion when trying to follow who builds what/when/how and it stops destroying intermediate linking information useful when tracing/debugging new features or issues in the build. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-14 01:15:44 +02:00
OUTPUT_MAP ${PROJECT_BINARY_DIR}/${ZEPHYR_FINAL_EXECUTABLE}.map
cmake: Introduce toolchain_ld_link_elf to abstract linker invocation Final step of linker abstraction: * Abstract zephyr_lnk by including it in toolchain_ld_link_elf. * Abstract relevant uses of target_link_libraries. * Introduce toolchain_ld_force_undefined_symbols. No functional change expected. This is motivated by the wish to abstract Zephyr's usage of toolchains, permitting non-intrusive porting to other (commercial) toolchains. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 16:32:36 +02:00
LIBRARIES_PRE_SCRIPT ${GKOF}
LINKER_SCRIPT ${PROJECT_BINARY_DIR}/linker_pass_final.cmd
LIBRARIES_POST_SCRIPT ""
DEPENDENCIES ${CODE_RELOCATION_DEP}
)
cmake: Rename kernel_elf to zephyr_final * KERNEL_ELF was easily confused with KERNEL_ELF_NAME and KERNEL_NAME. * kernel_elf as the name of the binary indicates it somehow only contains the kernel, which is not correct. Rename to zephyr_final as this is the reality: Zephyr elf has been linked again (a number of times) due to generated kernel files. Signed-off-by: Mark Ruvald Pedersen <mped@oticon.com>
2019-05-07 15:20:20 +02:00
set_property(TARGET ${ZEPHYR_FINAL_EXECUTABLE} PROPERTY LINK_DEPENDS ${PROJECT_BINARY_DIR}/linker_pass_final.cmd)
add_dependencies( ${ZEPHYR_FINAL_EXECUTABLE} ${PRIV_STACK_DEP} ${LINKER_PASS_FINAL_SCRIPT_TARGET})
# Use the pass2 elf as the final elf
set(logical_target_for_zephyr_elf ${ZEPHYR_FINAL_EXECUTABLE})
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
endif()
cmake: Export the target name of the final elf file to the app For the 'app' build scripts to be able to do post-processing on the elf file they need to know what the target name for the elf file is. In zephyr this name varies depending on whether one does a single or multiple link, so we export a variable with the name. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2018-10-16 13:25:04 +02:00
# Export the variable to the application's scope to allow the
# application to know what the name of the final elf target is.
set(logical_target_for_zephyr_elf ${logical_target_for_zephyr_elf} PARENT_SCOPE)
cmake: stop destroying intermediate link maps like zephyr_prebuilt.map The different linker steps are all hardcoded to the output filename "zephyr.map" and only the last one survives. Un-harcode. This removes some confusion when trying to follow who builds what/when/how and it stops destroying intermediate linking information useful when tracing/debugging new features or issues in the build. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-14 01:15:44 +02:00
# Override the base name of the last, "logical" .elf output (and last .map) so:
CMakeLists.txt: fix misleading logical_target_for_zephyr_elf comment The comment for: set_target_properties(${logical_target_for_zephyr_elf} PROPERTIES OUTPUT_NAME ${KERNEL_NAME}) was completely off-topic and making something relatively simple incredibly puzzling and time-consuming to understand. Re-order the if(GKSF OR GKOF) clauses so the two initializations of logical_target_for_zephyr_elf are close to each other and so the very short clause is not buried at the bottom of the long one. Other minor logical_target_for_zephyr_elf comment fixes. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-17 08:30:52 +02:00
# 1. it doesn't depend on the number of passes above and the
# post_build_commands below can always find it no matter which is it;
# 2. it can be defined in Kconfig
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_target_properties(${logical_target_for_zephyr_elf} PROPERTIES OUTPUT_NAME ${KERNEL_NAME})
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
set(post_build_commands "")
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
set(post_build_byproducts "")
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
cmake: stop destroying intermediate link maps like zephyr_prebuilt.map The different linker steps are all hardcoded to the output filename "zephyr.map" and only the last one survives. Un-harcode. This removes some confusion when trying to follow who builds what/when/how and it stops destroying intermediate linking information useful when tracing/debugging new features or issues in the build. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-14 01:15:44 +02:00
list(APPEND
post_build_commands
COMMAND
cmake -E rename ${logical_target_for_zephyr_elf}.map ${KERNEL_MAP_NAME}
)
kconfig: cmake: Support for images without gaps. Defines a Kconfig variable which allows the user to specify that any generated hex/bin/s19 file should not have filled gaps. This is done to support building in a multi image context, where several image files will be merged together. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-26 10:47:16 +01:00
if(NOT CONFIG_BUILD_NO_GAP_FILL)
# Use ';' as separator to get proper space in resulting command.
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
set(GAP_FILL "0xff")
kconfig: cmake: Support for images without gaps. Defines a Kconfig variable which allows the user to specify that any generated hex/bin/s19 file should not have filled gaps. This is done to support building in a multi image context, where several image files will be merged together. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-11-26 10:47:16 +01:00
endif()
cmake: Toolchain abstraction: Abstraction of print memory usage. The method for getting a memory usage report printed during build, is based on a GNU linker (ld) option flag, and thus is not necessarily supported by other toolchain binary tools. The introduced cmake macro allows for a given toolchain to specify how the memory usage report is to be generated, and whether the command for generation, if any, is to be added to the post_build_commands and the post_build_byproducts lists of the top level CMakeLists.txt The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-07-18 15:16:39 +02:00
if(CONFIG_OUTPUT_PRINT_MEMORY_USAGE)
# @Intent: Use the toolchain bintools method for printing memory usage
set(memUsageCmd "")
set(memUsageByProd "")
bintools_print_mem_usage(
RESULT_CMD_LIST memUsageCmd
RESULT_BYPROD_LIST memUsageByProd
)
list(APPEND
post_build_commands
${memUsageCmd}
)
list(APPEND
post_build_byproducts
${memUsageByProd}
)
endif()
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
if(CONFIG_BUILD_OUTPUT_HEX)
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
set(out_hex_cmd "")
set(out_hex_byprod "")
set(out_hex_sections_remove
.comment
COMMON
.eh_frame
)
bintools_objcopy(
RESULT_CMD_LIST out_hex_cmd
RESULT_BYPROD_LIST out_hex_byprod
STRIP_ALL
GAP_FILL ${GAP_FILL}
TARGET_OUTPUT "ihex"
SECTION_REMOVE ${out_hex_sections_remove}
FILE_INPUT ${KERNEL_ELF_NAME}
FILE_OUTPUT ${KERNEL_HEX_NAME}
)
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
list(APPEND
post_build_commands
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
${out_hex_cmd}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
list(APPEND
post_build_byproducts
${KERNEL_HEX_NAME}
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
${out_hex_byprod}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
endif()
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
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
if(CONFIG_BUILD_OUTPUT_BIN)
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
set(out_bin_cmd "")
set(out_bin_byprod "")
set(out_bin_sections_remove
.comment
COMMON
.eh_frame
)
bintools_objcopy(
RESULT_CMD_LIST out_bin_cmd
RESULT_BYPROD_LIST out_bin_byprod
STRIP_ALL
GAP_FILL ${GAP_FILL}
TARGET_OUTPUT "binary"
SECTION_REMOVE ${out_bin_sections_remove}
FILE_INPUT ${KERNEL_ELF_NAME}
FILE_OUTPUT ${KERNEL_BIN_NAME}
)
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
list(APPEND
post_build_commands
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
${out_bin_cmd}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
list(APPEND
post_build_byproducts
${KERNEL_BIN_NAME}
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
${out_bin_byprod}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
endif()
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
if(CONFIG_BUILD_OUTPUT_S19)
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
set(out_S19_cmd "")
set(out_S19_byprod "")
bintools_objcopy(
RESULT_CMD_LIST out_S19_cmd
RESULT_BYPROD_LIST out_S19_byprod
GAP_FILL ${GAP_FILL}
TARGET_OUTPUT "srec"
SREC_LEN 1
FILE_INPUT ${KERNEL_ELF_NAME}
FILE_OUTPUT ${KERNEL_S19_NAME}
)
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
list(APPEND
post_build_commands
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
${out_S19_cmd}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
list(APPEND
post_build_byproducts
${KERNEL_S19_NAME}
cmake: Toolchain abstraction: Abstraction of binary tool, objcopy. This abstracts the interface for generation of the objcopy command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 07:56:45 +02:00
${out_S19_byprod}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
endif()
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
if(CONFIG_OUTPUT_DISASSEMBLY)
cmake: Toolchain abstraction: Abstraction of binary tool, objdump. This abstracts the interface for generation of the objdump command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 08:01:39 +02:00
set(out_disassembly_cmd "")
set(out_disassembly_byprod "")
bintools_objdump(
RESULT_CMD_LIST out_disassembly_cmd
RESULT_BYPROD_LIST out_disassembly_byprod
DISASSEMBLE_SOURCE
FILE_INPUT ${KERNEL_ELF_NAME}
FILE_OUTPUT ${KERNEL_LST_NAME}
)
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
list(APPEND
post_build_commands
cmake: Toolchain abstraction: Abstraction of binary tool, objdump. This abstracts the interface for generation of the objdump command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 08:01:39 +02:00
${out_disassembly_cmd}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
list(APPEND
post_build_byproducts
${KERNEL_LST_NAME}
cmake: Toolchain abstraction: Abstraction of binary tool, objdump. This abstracts the interface for generation of the objdump command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 08:01:39 +02:00
${out_disassembly_byprod}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
endif()
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
if(CONFIG_OUTPUT_STAT)
cmake: Toolchain abstraction: Abstraction of binary tool, readelf. This abstracts the interface for generation of the readelf command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 08:04:12 +02:00
set(out_stat_cmd "")
set(out_stat_byprod "")
bintools_readelf(
RESULT_CMD_LIST out_stat_cmd
RESULT_BYPROD_LIST out_stat_byprod
HEADERS
FILE_INPUT ${KERNEL_ELF_NAME}
FILE_OUTPUT ${KERNEL_STAT_NAME}
)
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
list(APPEND
post_build_commands
cmake: Toolchain abstraction: Abstraction of binary tool, readelf. This abstracts the interface for generation of the readelf command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 08:04:12 +02:00
${out_stat_cmd}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
list(APPEND
post_build_byproducts
${KERNEL_STAT_NAME}
cmake: Toolchain abstraction: Abstraction of binary tool, readelf. This abstracts the interface for generation of the readelf command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 08:04:12 +02:00
${out_stat_byprod}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
endif()
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
if(CONFIG_BUILD_OUTPUT_STRIPPED)
cmake: Toolchain abstraction: Abstraction of binary tool, strip. This abstracts the interface for generation of the strip command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 08:06:54 +02:00
set(out_stripped_cmd "")
set(out_stripped_byprod "")
bintools_strip(
RESULT_CMD_LIST out_stripped_cmd
RESULT_BYPROD_LIST out_stripped_byprod
STRIP_ALL
FILE_INPUT ${KERNEL_ELF_NAME}
FILE_OUTPUT ${KERNEL_STRIP_NAME}
)
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
list(APPEND
post_build_commands
cmake: Toolchain abstraction: Abstraction of binary tool, strip. This abstracts the interface for generation of the strip command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 08:06:54 +02:00
${out_stripped_cmd}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
list(APPEND
post_build_byproducts
${KERNEL_STRIP_NAME}
cmake: Toolchain abstraction: Abstraction of binary tool, strip. This abstracts the interface for generation of the strip command line, by naming the desired actions instead of directly setting the command parameters, which then opens up for other binary tool sets which may require different arguments to achieve the desired result. The intent here is to abstract Zephyr's dependence on toolchains, thus allowing for easier porting to other, perhaps commercial, toolchains and/or usecases. No functional change expected. Signed-off-by: Danny Oerndrup <daor@demant.com>
2019-08-01 08:06:54 +02:00
${out_stripped_byprod}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
)
endif()
if(CONFIG_BUILD_OUTPUT_EXE)
list(APPEND
post_build_commands
COMMAND
${CMAKE_COMMAND} -E copy ${KERNEL_ELF_NAME} ${KERNEL_EXE_NAME}
)
list(APPEND
post_build_byproducts
${KERNEL_EXE_NAME}
)
endif()
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
CMakeLists: Introduce extra post build commands This patchset introduces support for building board specific custom images. Any board which needs to build a custom image (a post-processed zephyr.bin) should inject the post_build_command from a script in the corresponding board directory. Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
2019-01-25 07:23:13 +01:00
get_property(extra_post_build_commands
GLOBAL PROPERTY
extra_post_build_commands
)
list(APPEND
post_build_commands
${extra_post_build_commands}
)
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
get_property(extra_post_build_byproducts
GLOBAL PROPERTY
extra_post_build_byproducts
)
list(APPEND
post_build_byproducts
${extra_post_build_byproducts}
)
CMakeLists.txt: fix misleading logical_target_for_zephyr_elf comment The comment for: set_target_properties(${logical_target_for_zephyr_elf} PROPERTIES OUTPUT_NAME ${KERNEL_NAME}) was completely off-topic and making something relatively simple incredibly puzzling and time-consuming to understand. Re-order the if(GKSF OR GKOF) clauses so the two initializations of logical_target_for_zephyr_elf are close to each other and so the very short clause is not buried at the bottom of the long one. Other minor logical_target_for_zephyr_elf comment fixes. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-17 08:30:52 +02:00
# Add post_build_commands to post-process the final .elf file produced by
# either the ZEPHYR_PREBUILT_EXECUTABLE or the KERNEL_ELF executable
# targets above.
cmake: Generate POST_BUILD items based on KConfig Signed-off-by: Sebastian Boe <sebastian.boe@nordicsemi.no>
2017-11-20 15:37:59 +01:00
add_custom_command(
TARGET ${logical_target_for_zephyr_elf}
POST_BUILD
${post_build_commands}
cmake: Mark post_build files as BYPRODUCTS Mark post_build files as BYPRODUCTS to allow custom commands to depend on them. Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-05-10 10:06:32 +02:00
BYPRODUCTS
${post_build_byproducts}
CMakeLists.txt: fix misleading logical_target_for_zephyr_elf comment The comment for: set_target_properties(${logical_target_for_zephyr_elf} PROPERTIES OUTPUT_NAME ${KERNEL_NAME}) was completely off-topic and making something relatively simple incredibly puzzling and time-consuming to understand. Re-order the if(GKSF OR GKOF) clauses so the two initializations of logical_target_for_zephyr_elf are close to each other and so the very short clause is not buried at the bottom of the long one. Other minor logical_target_for_zephyr_elf comment fixes. Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-04-17 08:30:52 +02:00
COMMENT "Generating files from ${KERNEL_ELF_NAME} for 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
# NB: COMMENT only works for some CMake-Generators
CMakeLists: Introduce extra post build commands This patchset introduces support for building board specific custom images. Any board which needs to build a custom image (a post-processed zephyr.bin) should inject the post_build_command from a script in the corresponding board directory. Signed-off-by: Rajavardhan Gundi <rajavardhan.gundi@intel.com>
2019-01-25 07:23:13 +01: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
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
# To populate with hex files to merge, do the following:
# set_property(GLOBAL APPEND PROPERTY HEX_FILES_TO_MERGE ${my_local_list})
# Note that the zephyr.hex file will not be included automatically.
get_property(HEX_FILES_TO_MERGE GLOBAL PROPERTY HEX_FILES_TO_MERGE)
if(HEX_FILES_TO_MERGE)
# Merge in out-of-tree hex files.
cmake: fix incorrect lower case variable This patch fixes a bug where a incorrect lower case variable 'MERGED_HEX_NAME' resulted in the 'flash' target not getting the correct path to the hex file to flash. This since cmake/flash/CMakeLists.txt uses the variable ${MERGED_HEX_NAME}. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 09:32:32 +01:00
set(MERGED_HEX_NAME merged.hex)
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
add_custom_command(
cmake: fix incorrect lower case variable This patch fixes a bug where a incorrect lower case variable 'MERGED_HEX_NAME' resulted in the 'flash' target not getting the correct path to the hex file to flash. This since cmake/flash/CMakeLists.txt uses the variable ${MERGED_HEX_NAME}. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 09:32:32 +01:00
OUTPUT ${MERGED_HEX_NAME}
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
COMMAND
${PYTHON_EXECUTABLE}
${ZEPHYR_BASE}/scripts/mergehex.py
cmake: fix incorrect lower case variable This patch fixes a bug where a incorrect lower case variable 'MERGED_HEX_NAME' resulted in the 'flash' target not getting the correct path to the hex file to flash. This since cmake/flash/CMakeLists.txt uses the variable ${MERGED_HEX_NAME}. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 09:32:32 +01:00
-o ${MERGED_HEX_NAME}
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
${HEX_FILES_TO_MERGE}
DEPENDS ${HEX_FILES_TO_MERGE} ${logical_target_for_zephyr_elf}
)
cmake: fix incorrect lower case variable This patch fixes a bug where a incorrect lower case variable 'MERGED_HEX_NAME' resulted in the 'flash' target not getting the correct path to the hex file to flash. This since cmake/flash/CMakeLists.txt uses the variable ${MERGED_HEX_NAME}. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 09:32:32 +01:00
add_custom_target(mergehex ALL DEPENDS ${MERGED_HEX_NAME})
cmake: flash: Conditional dependency to 'mergehex' This patch adds a dependency from the 'flash' target to the 'mergehex' target IF files to be merged are configured. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-12-05 10:15:40 +01:00
list(APPEND FLASH_DEPS mergehex)
cmake: flash: scripts: Include externally built hex files Allow user to add externally built hex files to the cmake property HEX_FILES_TO_MERGE. The hex files in this list will be merged with the hex file generated when building the zephyr application. This allows users to leverage the application configuration available in Kconfig and CMake to help decide what hex file should be merged with the zephyr application. Signed-off-by: Håkon Øye Amundsen <haakon.amundsen@nordicsemi.no>
2018-10-30 08:39:13 +01:00
endif()
cmake: support other emulation platforms/runners Right now we are hardcoded to only qemu, with the native port, we make this more generic and support this in a plugin mode where a running has its own cmake definitons implementing the various targets. Signed-off-by: Anas Nashif <anas.nashif@intel.com> Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2017-11-22 00:54:55 +01:00
if(EMU_PLATFORM)
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/emu/${EMU_PLATFORM}.cmake)
cmake: cleanup qemu runner configuration All runner logic was implemented in qemu.cmake, remove the generic stuff and make qemu.cmake qemu specific. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-21 22:45:45 +01:00
else()
add_custom_target(run
COMMAND
${CMAKE_COMMAND} -E echo
"==================================================="
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
"Emulation/Simulation not supported with this board."
cmake: cleanup qemu runner configuration All runner logic was implemented in qemu.cmake, remove the generic stuff and make qemu.cmake qemu specific. Signed-off-by: Anas Nashif <anas.nashif@intel.com>
2017-12-21 22:45:45 +01:00
"==================================================="
)
cmake: support other emulation platforms/runners Right now we are hardcoded to only qemu, with the native port, we make this more generic and support this in a plugin mode where a running has its own cmake definitons implementing the various targets. Signed-off-by: Anas Nashif <anas.nashif@intel.com> Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
2017-11-22 00:54:55 +01:00
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
add_subdirectory(cmake/flash)
add_subdirectory(cmake/usage)
add_subdirectory(cmake/reports)
cmake: silence "WARNING: ASSERTs enabled" when CONFIG_TEST is true TEST configurations don't need to be warned that they're using test techniques with some side-effects. On a typical sanitycheck invocation, this warning is one of the only two that appears in most test runs. In other words this commit gets rid of half of the entire grep -ri '[[:blank:]]warn' noise that obscures any work-in-progress warnings or platform specific warnings in the logs (typically: device tree warnings). Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-17 22:26:11 +02:00
if(NOT CONFIG_TEST)
build: suppress asserts warning if forced off This was being incorrectly printed. Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
2018-05-24 22:18:36 +02:00
if(CONFIG_ASSERT AND (NOT CONFIG_FORCE_NO_ASSERT))
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
message(WARNING "
------------------------------------------------------------
--- WARNING: __ASSERT() statements are globally ENABLED ---
cmake: fix warning message This commit provides a minor fix to a CMake output text which warns the user that ASSERT() statements are enabled. Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
2018-05-31 11:05:12 +02:00
--- The kernel will run more slowly and use more memory ---
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
)
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
endif()
cmake: silence "WARNING: ASSERTs enabled" when CONFIG_TEST is true TEST configurations don't need to be warned that they're using test techniques with some side-effects. On a typical sanitycheck invocation, this warning is one of the only two that appears in most test runs. In other words this commit gets rid of half of the entire grep -ri '[[:blank:]]warn' noise that obscures any work-in-progress warnings or platform specific warnings in the logs (typically: device tree warnings). Signed-off-by: Marc Herbert <marc.herbert@intel.com>
2019-06-17 22:26:11 +02:00
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
if(CONFIG_BOARD_DEPRECATED)
message(WARNING "
WARNING: The board '${BOARD}' is deprecated and will be
removed in version ${CONFIG_BOARD_DEPRECATED}"
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
)
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
endif()
CMakeLists.txt: Call toolchain_cc_nostdinc() at the end To let any other zephyr_system_include_directories() directives act first and get these paths in an order allowing Zephyr's stuff override compiler headers. Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
2019-06-06 20:12:14 +02:00
# @Intent: Set compiler specific flags for standard C includes
# Done at the very end, so any other system includes which may
# be added by Zephyr components were first in list.
toolchain_cc_nostdinc()
Reference in a new issue Copy permalink