Recipes are much more readable with whitespace around the assignment operators.
Fix various assignments in OE-Core to show this is definitely the preferred
formatting.
(From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: copyright years
(From OE-Core rev: eda9c9b556c6671e009bc637acb151580796223b)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When `-pipe` is enabled, GCC passes data between its different
executables using pipes instead of temporary files. This leads to issues
when cmake attempts to infer compiler internals via the `-v` parameter
as each executable will print to `stderr` in parallel.
In turn this may lead to compilation issues down the line as for example
the system include directories could not be determined properly which
may then propagate to issues such as:
recipe-sysroot/usr/include/c++/11.3.0/cstdlib:75:15: fatal error:
stdlib.h: No such file or directory
| 75 | #include_next <stdlib.h>
| | ^~~~~~~~~~
| compilation terminated.
| ninja: build stopped: subcommand failed.
| WARNING: exit code 1 from a shell command.
Fix this stripping `-pipe` from the command line used to determine
compiler internals.
(From OE-Core rev: 34fa8230163e5ed1c6668bf800c45a173c6490ca)
Signed-off-by: Philip Lorenz <philip.lorenz@bmw.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog (https://cmake.org/cmake/help/latest/release/3.30.html#updates):
3.30.5
- The project(<PROJECT-NAME>) command now sets
<PROJECT-NAME>_SOURCE_DIR, <PROJECT-NAME>_BINARY_DIR, and
<PROJECT-NAME>_IS_TOP_LEVEL as non-cache variables only if they are
already set as non-cache variables when project() is invoked. Cache
entries by the same names are always set as before. This refines
3.30.3's behavior change to restore behavior of nested directories
that call project() with the same project name, and it addresses the
bug in the implementation introduced in 3.30.4.
3.30.4
- The project(<PROJECT-NAME>) command now sets
<PROJECT-NAME>_SOURCE_DIR, <PROJECT-NAME>_BINARY_DIR, and
<PROJECT-NAME>_IS_TOP_LEVEL as normal variables only if they are
already set as cache or non-cache variables when project() is
invoked. Cache entries by the same names are always set as before.
This refines 3.30.3's behavior change to restore behavior of nested
directories that call project() with the same project name, but the
implementation in this release is flawed (this release note has been
retoractively updated). It can result in different behavior between
the first and subsequent runs. Do not use CMake 3.30.4 if your
project contains nested calls to project() with the same project
name and you use these variables.
3.30.3
- The project(<PROJECT-NAME>) command now sets
<PROJECT-NAME>_SOURCE_DIR, <PROJECT-NAME>_BINARY_DIR, and
<PROJECT-NAME>_IS_TOP_LEVEL as normal variables in addition to
setting them as cache entries. This is needed to preserve support
for some FetchContent use cases under policy CMP0169's NEW behavior.
- The FindPython and FindPython3 modules now define, respectively, the
Python_DEFINITIONS and Python3_DEFINITIONS variables on Windows to
support development with the free threaded version of Python. The
INTERFACE_COMPILE_DEFINITIONS target property is also defined for
the various targets provided by these modules.
(From OE-Core rev: 9783c7af634e6bd3e29ef350f61b444c0c6087f5)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since we want to be able to stop unpacking to WORKDIR, correct the WORKDIR
references in recipe do_compile/do_install tasks to use UNPACKDIR in the
appropraite places instead.
(From OE-Core rev: d73595df69667fe9d12ecd407b77a0b8dae2109c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As discussion in [YOCTO #14717] cmake contains a OEToolchainConfig.cmake
file to configure the toolchain correctly in cross-compile build for recipes
using cmake.
The variable CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES value updates incorrectly
during do_compile the code. Due to this getting sporadic error like below,
fatal error: stdlib.h: No such file or directory
| 75 | #include_next <stdlib.h>
| | ^~~~~~~~~~
| compilation terminated.
| ninja: build stopped: subcommand failed.
| WARNING: exit code 1 from a shell command.
As cmake already correctly initializes the variable from environment,
So we have to unset it in the toolchain file to avoid overwriting the
variable definition again.
(From OE-Core rev: 5aeada5793af53e8c93940952d4f314474dca4c2)
Signed-off-by: aszh07 <mail2szahir@gmail.com>
Signed-off-by: Zahir Hussain <zahir.basha@kpit.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CMAKE_TOOLCHAIN_FILE is now also a supported environment
variable, we can export it directly. There's no need to
use a OE specific patch to add OE_CMAKE_TOOLCHAIN_FILE
support.
(From OE-Core rev: b061149ad06ff3b9d30de0bbd2b698c711a241c7)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: Copyright year changed from 2022 -> 2023
- Copyright 2000-2022 Kitware, Inc. and Contributors
+ Copyright 2000-2023 Kitware, Inc. and Contributors
Call bootstrap directly without wrapping it with configure
since all it does it find the sourcedir
(From OE-Core rev: f038e40328eff37fe5d16310853448ba21e5c9f4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is for breaking circular dependency in following condition:
After enabling PACKAGECONFIG nghttp2 for curl, the dependency chain is:
curl-native -> nghttp2-native -> cmake-native -> curl-native.
So change to use internal cmcurl library to fix this. And as using
system curl library before, disable nghttp2 and use system openssl
library for cmcurl.
(From OE-Core rev: f9a5f9fdb69bb61242dc65ed83704f727491ecca)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[v2 hopefully fixes the From: mangling by the ML, no functional changes]
Trying to build cmake-native on a host system where curl was built with cmake
(resulting in CURLConfig.cmake and friends, which do not use the same naming
schemes expected by cmake-native's build process, being installed to a system
wide cmake directory like /usr/lib64/cmake/CURL) results in undefined
references to all libcurl symbols.
The problem is that cmake-native sees and uses the system wide
/usr/lib64/cmake/CURL/CURLConfig.cmake, which defines CURL::libcurl and
CURL::curl as opposed to setting ${CURL_LIBRARIES} as expected by
cmake-native.
find_package(CURL) (cmake-native's CMakeLists.txt, line 478) succeeds, but
incorrectly uses the system wide CURLConfig.cmake, resulting
CMAKE_CURL_LIBRARIES to be set to an empty string (cmake-native's
CMakeLists.txt, line 484), causing the cmake-native build to miss -lcurl.
The simplest fix is to let cmake know the right value for
CURL_LIBRARIES. Making it -lcurl should always work with libcurl-native
in recipe-sysroot-native.
[YOCTO #14951]
(From OE-Core rev: 2659c735a464c956b4fca0894a5aed27a0fe7e37)
Signed-off-by: Bernhard Rosenkränzer <bero@baylibre.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building using an SDK, cmake complains that the target
architecture 'cortexa53-crypto' is unknown. The same build in bitbake
uses the target architecture 'aarch64'.
Set CMAKE_SYSTEM_PROCESSOR the same as for bitbake.
(From OE-Core rev: d32a6225eefce2073a1cd401034b5b4c68351bfe)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As discussied in [YOCTO #14717] cmake contains a OEToolchainConfig.cmake
file to configure the toolchain correctly in cross-compile build for recipes
using cmake. The CMAKE_ASM_FLAGS are the configuration are meant for assembly,
but the spelling is incorrect and the Flag is ASFLAGS for gcc and other compilers.
So this variable might neever have worked and it is better for
recipes to specify their own.
(From OE-Core rev: 72729ffbab53f95ee9dd1bc22913d9b864495930)
Signed-off-by: Martin Beeger <martin.beeger@online.de>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
in target and native variant a different set of vendored libraries
is pulled from the cmake sources.
Add those licenses and there texts
(From OE-Core rev: fc6c1951dd7e53791a9d92610dfc2eefab4c2a4a)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The patch creates ${MULTIMACH_TARGET_SYS}-toolchain.cmake file
at ${SDK_INSTALL_DIR}/sysroots/${SDK_SYS}/usr/share/cmake/, which is
per-toolchain CMake toolchain file containing arch-specific values
and independent of OE environment variables.
The file gets created after installing SDK toolchain installer
ined by running "bitbake -c populate_sdk <image>".
The changes are similar to meson-setup.py which is used to
create arch-specific
${SDK_INSTALL_DIR}/sysroots/${SDK_SYS}/usr/share/meson/*-meson.cross
[YOCTO #14644]
Tested-by: Jan Dorniak <jaskij@gmail.com>
(From OE-Core rev: 42e68397ec74b3cd8ae5df45355c8f6254b48cd8)
Signed-off-by: Jagadeesh Krishnanjanappa <workjagadeesh@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
refresh 0001-CMakeDetermineSystem-use-oe-environment-vars-to-load.patch
Changelog:
==========
* The :command:'while' command again ignores errors in condition evaluation
as CMake 3.21 and below did. This bug was fixed in 3.22.0, but exposed
errors in existing projects. The fix has been reverted to restore
compatibility. The fix may be restored in a future version of CMake
via a policy.
(From OE-Core rev: 146ceceaf81639085a82fd94d30ea84150a75e3a)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This drops the file count for cmake-native from ~3000 to ~1700
which is a decent chunk of files not to be copying to each native
sysroot for no reason.
(From OE-Core rev: 6e561619a2a2b688735deae968eb66027fd4b9f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As discussion in [YOCTO #14717] cmake contains a OEToolchainConfig.cmake
file to configure the toolchain correctly in cross-compile build for recipes
using cmake. The variable CMAKE_LDFLAGS_FLAGS is spelled incorrectly, cmake expects
CMAKE_SHARED_LINKER_FLAGS, CMAKE_STATIC_LINKER_FLAGS, CMAKE_EXE_LINKER_FLAGS and
CMAKE_MODULE_LINKER_FLAGS to be set instead. As cmake already correctly initializes
these from environment there is no need to specify the linker flags in the toolchain
file at all. So this just removes the variable, as its value was also set wrong.
(From OE-Core rev: 52e59a5b37f55905ee693a99f9ffc34ed41b4283)
Signed-off-by: Martin Beeger <martin.beeger@online.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
