Appropriately setting the `--target` flag is necessary when using clang
and building for a target other than the default. Zephyr generally
accomplishes this by setting the CMAKE_<LANG>_COMPILER_TARGET variables and
allowing cmake to automatically provide the `--target` flag when building.
For the external_lib sample, however, cmake can't add the flag and it was
not otherwise exported. As such, clang typically threw errors when building
this sample for any non-default targets due to mismatches between
target-specific flags and the default target.
To fix this, ensure we select the correct target by checking if
CMAKE_C_COMPILER_TARGET has been defined and adding
`--target=<triple>` to the list of flags that are exported if so.
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
This provides a better error message when building with CMake and
forgetting ZEPHYR_BASE or not registering Zephyr in the CMake package
registry. See parent commit for more details (split from parent for
better readability).
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
Using find_package to locate Zephyr.
Old behavior was to use $ENV{ZEPHYR_BASE} for inclusion of boiler plate
code.
Whenever an automatic run of CMake happend by the build system / IDE
then it was required that ZEPHYR_BASE was defined.
Using ZEPHYR_BASE only to locate the Zephyr package allows CMake to
cache the base variable and thus allowing subsequent invocation even
if ZEPHYR_BASE is not set in the environment.
It also removes the risk of strange build results if a user switchs
between different Zephyr based project folders and forgetting to reset
ZEPHYR_BASE before running ninja / make.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Recursive make should be invoked as $(MAKE) and not "make" for reasons
documented at
https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
$(MAKE) is what CMake puts in all the CMakeFiles/Makefile2 it generates,
it doesn't use "make" either.
Issue found thanks to the following warning:
build.log:make[4]: warning: jobserver unavailable: using -j1.
Add '+' to parent make rule.
If CMake is invoked with -GNinja or other then fall back on "make" as
before and pray that it's available.
Fast reproduction with:
make -j2 -C build clean mylib_project VERBOSE=1
Build directories have been compared before/after this change and
there's zero difference except the generated
mylib_project.dir/build.make file (and the warning above) when using
make.
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
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>
Move to latest cmake version with many bug fixes and enhancements.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
When using an IDE (e.g. Eclipse, Qt Creator), the project name gets
displayed. This greatly simplifies the navigation between projects when
having many of them open at the same time. Naming every project "NONE"
defeats this functionality.
This patch tries to use sensible project names while not duplicating
too much of what is already represented in the path. This is done by
using the name of the directory the relevant CMakeLists.txt file is
stored in. To ensure unique project names in the samples (and again, in
the tests folder) folder, small manual adjustments have been done.
Signed-off-by: Reto Schneider <code@reto-schneider.ch>
Prepend the text 'cmake_minimum_required(VERSION 3.8.2)' into the
application and test build scripts.
Modern versions of CMake will spam users with a deprecation warning
when the toplevel CMakeLists.txt does not specify a CMake
version. This is documented in bug #8355.
To resolve this we include a cmake_minimum_required() line into the
toplevel build scripts. Additionally, cmake_minimum_required is
invoked from within boilerplate.cmake. The highest version will be
enforced.
This patch allows us to afterwards change CMake policy CMP000 from OLD
to NEW which in turn finally rids us of the verbose warning.
The extra boilerplate is considered more acceptable than the verbosity
of the CMP0000 policy.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
CMake has several prototypes/signatures for the function
'target_link_libraries'. This commit migrates the usage of
'target_link_libraries' on Zephyr CMake libraries from the old 'plain'
signature to the new '<PRIVATE|PUBLIC|INTERFACE>' signature.
For technical reasons the two signatures can not be mixed. Each
library must exclusively use either the old or new signature.
The 'old' plain signature is equivalent to using the PUBLIC
signature. Migrating to use 'PUBLIC' is therefore expected to be a
safe change.
After the migration it will be possible to use the PRIVATE and
INTERFACE signatures on Zephyr CMake libraries. This is useful for
instance to fix issue 8438.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
Having a library being GLOBAL, although not default behaviour, or
necessary for the sample, is expected behaviour for a library. It is
expected that like normal libraries, the target name will be
accessible from outside of the CMakeLists.txt file that created it.
Since samples are used as reference code, we specify GLOBAL so that
libraries are created with this intuitive behaviour.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
This samples was failing to build with Ninja because Ninja detected
that libmylib.a was missing. Adding it as a BYPRODUCT in the
ExternalProject fixes the issue.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
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>
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>
