linux/poky.git/meta/classes/cmake.bbclass, branch hardknott-next

cmake.bbclass: remove ${B} before cmake_do_configure

2021-05-04T21:57:51+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: db6a315e5f6de02e226e582f878a83c427fd87cc) Signed-off-by: Kai Kang Signed-off-by: Richard Purdie (cherry picked from commit 0fb6280432a36985590d9a714a5f11164aaebb51) Signed-off-by: Anuj Mittal 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

cmake: fix Python executable with cmake

2020-04-05T10:46:38+00:00

Currently, CMake has two ways of finding Python executables: FindPythonInterp and FindPython/FindPython3. FindPythonInterp is deprecated and may be removed at some point. Currently, python3native sets PYTHON_EXECUTABLE, which FindPythonInterp uses. This is a problem for a few reasons: - Setting PYTHON_EXECUTABLE as an environment variable doesn't work, as CMake needs it to be set as an explicit CMake option via -D. - Projects using the newer FindPython/FindPython3 don't pickup the right Python, as the newer routines use Python_EXECUTABLE and Python3_EXECUTABLE. Fix this by setting PYTHON_EXECUTABLE, Python_EXECUTABLE, and Python3_EXECUTABLE using -D options to EXTRA_OECMAKE. The CMake routines are documented below: https://cmake.org/cmake/help/latest/module/FindPythonInterp.html https://cmake.org/cmake/help/latest/module/FindPython.html https://cmake.org/cmake/help/latest/module/FindPython3.html (From OE-Core rev: a22200a646eaf42cd4902a2fe3358d29717ac129) Signed-off-by: Martin Kelly Signed-off-by: Richard Purdie

cmake: prefer CMAKE_BUILD_PARALLEL_LEVEL

2020-02-04T15:56:29+00:00

cmake 3.12 introduced this environment variable. Prefer it to passing PARALLEL_MAKE and PARALLEL_MAKEINST on the cmake command line, because it gets passed to second stage cmake invocations while command-line arguments do not (for example, multi-stage clang builds) (From OE-Core rev: cdd44c93f02bb8cc2fa773e13c8ce36e3da23921) Signed-off-by: Daniel McGregor Signed-off-by: Richard Purdie

cmake.bbclass: Define LIB_SUFFIX

2019-12-30T23:39:09+00:00

This variable is used in lot of cmake based packages to denote libdir in multilib environments, now a days there is a better way to include GNUInstallDirs module but thats upto these packages to adopt. Defining this helps compiling a bunch of recipes in extended layers when using multilibbed builds. (From OE-Core rev: 24f630ce36e803c54ad6cff00215abd0e7b77b77) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

cmake: Add a knob for cmake VERBOSE settings

2019-12-30T08:47:13+00:00

Setting VERBOSE always, while is fine on one hand for debugging, its coming at an expense of creating lots and lots of logs, e.g. qtwebkit compile logs alone with VERBOSE is 163MB, there are many other large packages which use cmake e.g. WPE, webkitgtk etc which are in same range with out this option on, the logs reduce to 861K and also speeds up build a notch If user needs to disable these logs for a recipe or globally CMAKE_VERBOSE = "" in recipe or in global metadata e.g. local.conf (From OE-Core rev: f8d2cd0025f97819898da26041f353d527a27952) Signed-off-by: Khem Raj Cc: Ross Burton Cc: Andre McCurdy Signed-off-by: Richard Purdie