linux/poky.git/meta/classes/cmake.bbclass, branch yocto-4.0.12

cmake: add CMAKE_SYSROOT to generated toolchain file

2023-05-03T14:17:12+00:00

This already got fixed in the toolchain file that is used during development in https://github.com/openembedded/openembedded-core/commit/cb42802f2fe1760f894a435b07286bca3a220364 The toolchain file generated by the cmake.bbclass however does not set CMAKE_SYSROOT. Under certain circumstances this also leads to the error: `"stdlib.h: No such file or directory #include_next "` during the build of a recipe. An example where this accured was during the upgrade of the Apache Thrift recipe in meta-openembedded to 0.11.0. With this change the build works out of the box. CMAKE_SYSROOT must only be set when crosscompiling, otherwise it will interfere with the native compiler headers. (From OE-Core rev: 1105c67d554bcd155e8247cb16efc8d6a642444f) Signed-off-by: Pascal Bach (from http://lists.openembedded.org/pipermail/openembedded-core/2018-August/154791.html ) Signed-off-by: Mikko Rapeli Signed-off-by: Poonam Jadhav Signed-off-by: Steve Sakoman

Revert "cmake.bbclass: Set CXXFLAGS and CFLAGS"

2022-03-04T17:14:15+00:00

This reverts commit 47594d59ec4ab82fcf87d3c590caf7c46a6bfdff. This patch was introduced 5 years ago as a temporary workaround to fix an upstream bug. Currently with that patch the following flags are duplicated: OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CFLAGS}" OECMAKE_C_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS} ${LDFLAGS}" OECMAKE_CXX_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} ${LDFLAGS}" The duplicated flags is used in the toolchain.cmake: set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "CFLAGS" ) set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "CXXFLAGS" ) set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE STRING "LDFLAGS" ) CC: Khem Raj (From OE-Core rev: a83623a54a375d3ae9198a135b94379881a2b7a5) Signed-off-by: Jose Quaresma Signed-off-by: Richard Purdie

cmake: stop FetchContent from fetching content

2022-02-12T17:05:35+00:00

CMake includes a FetchContent module, which will download further source code at configure time. With the network isolation this will now fail, but as not all environments support network isolation we can tell cmake to not download either for extra safety. (From OE-Core rev: 138df1940fff303de48c98a95ac1bbaef4f120e2) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

Convert to new override syntax

2021-08-02T14:44:10+00:00

This is the result of automated script conversion: scripts/contrib/convert-overrides.py converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie

cmake.bbclass: remove ${B} before cmake_do_configure

2021-04-24T16:53:05+00:00

It is fallible to remove ${B} in directory ${B} itself. And it does fail when call bitbake by third-party wrapper script. Use flag 'cleandirs' to remove ${B} first if build out of source tree. (From OE-Core rev: 0fb6280432a36985590d9a714a5f11164aaebb51) Signed-off-by: Kai Kang Signed-off-by: Richard Purdie

cmake: Fully-qualified path to ar

2021-03-20T18:54:56+00:00

We (correctly enough) pass in our AR to cmake via the toolchain file, but unlike the other cross-compilation tools (CC, CXX, ranlib, etc), cmake does not then do its own search in the PATH for our AR. By using cmake's own find_program() to search the PATH, make works as expected from the commandline, outside of bitbake. (From OE-Core rev: e9180c9575f0723b51915a0da58452511b6b03bf) Signed-off-by: Douglas Royds Signed-off-by: Richard Purdie

cmake.bbclass: Create cmake arch mapping for ppc64le

2021-03-14T16:33:59+00:00

(From OE-Core rev: 698ece14e22d0efd9074493ef443b2cce5625d51) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

cmake: set CMAKE_EXPORT_NO_PACKAGE_REGISTRY

2021-02-19T11:17:11+00:00

if a cmake file uses export(PACKAGE) command it creates a folder ~/.cmake/package/ in the current user's home-dir. fix this host contermination by setting CMAKE_EXPORT_NO_PACKAGE_REGISTRY to ON by default, which makes the export() command do nothing (From OE-Core rev: fc7bd81cfe52c35fe26d146c1def8a7493bd2e25) Signed-off-by: Konrad Weihmann Signed-off-by: Richard Purdie

cmake.bbclass: Rework compiler program variables for allarch

2020-08-10T17:14:59+00:00

CMake projects can specify the NONE project type. Projects that do this do not use any C or C++ compiler, this currently works fine with caveat that when changing the machine/arch the compiler is different causing signature hash differences. To avoid the signature hash differences clear the associated C/CXX compiler variables. In order to achieve this with overrides, simplify the existing construction of the values using a python function and variable setting and remove the anonymous variable setup. (From OE-Core rev: e0657ff13453deedbdcf7c2f8a8854f601c659bd) Signed-off-by: Nathan Rossi Signed-off-by: Richard Purdie

classes/cmake: Fix host detection

2020-07-22T11:45:56+00:00

Fixes the class to use HOST_OS and HOST_ARCH to set the cmake SYSTEM variables. The HOST variables should be used instead of TARGET_OS/TARGET_ARCH because we want to control how cmake compiles for where the package is going to run (the host), not what it will be generating output for (the target). The distinction is only really relevant when building canadian cross recipes. Also fix up the host OS detection to account for MinGW by setting CMAKE_SYSTEM_NAME to "Windows". This eliminates the need for meta-mingw to patch this in all the cmake recipes it builds. (From OE-Core rev: 01245db2893e39ffb5d4a00e4689f048d0698974) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie