linux/poky.git/meta/classes/cmake.bbclass, branch uninative-2.10

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

classes/cmake: Use relative RPATHs

2019-11-27T13:25:18+00:00

In most cases, the RPATH is stripped out when the ELF file is packages, but by then the damage is done from a reproducible perspective because this absolute path is hashed as part of the build-id generated at link time ([1] has a good explanation). Fortunately, newer cmake has an option to generated relative RPATHs that use $ORIGIN to set the path, so set it in the toolchain file. [1]: https://gitlab.kitware.com/cmake/cmake/issues/18413 (From OE-Core rev: 44e77d3f97af4cd4ad8bc0984f093a116a830986) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

cmake.bbclass: add HOSTTOOLS_DIR to CMAKE_FIND_ROOT_PATH

2019-10-23T15:30:35+00:00

The find_program command will fail if it is used on a tool that is listed in ASSUME_PROVIDED. This is because these tools are in the hosttools directory which is not listed in CMAKE_FIND_ROOT_PATH so cmake will not find them. Adding the directory HOSTTOOLS_DIR to the CMAKE_FIND_ROOT_PATH variable fixes the initial issue of needing to search for tools in ASSUME_PROVIDED. Note that this change alone does not fix the issue because find_program will by default only look into the subdirectories bin and usr/bin under the paths in CMAKE_FIND_ROOT_PATH to find the programs and the hosttools directory has instead the symlinks directly present without these subdirectories. Set CMAKE_PROGRAM_PATH to by default include the root directory so find_program can search the hosttools directory without needing the prefix directories. (From OE-Core rev: 7847f431cd8db59fce8c9401a603c4b0678ee16d) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

cmake: Clarify comment in cmake toolchain file

2019-06-20T12:14:22+00:00

The comment is misleading and there was confusion in a bug report. In the native case STAGING_DATADIR would be equal to the native value so there isn't any issue but tweak the comment. [YOCTO #12761] (From OE-Core rev: 0fdf76305a3cb543c23d6122c523ce5c2af04a0c) Signed-off-by: Richard Purdie

cmake: Avoid passing empty prefix to os.path.relpath

2019-06-12T09:54:40+00:00

With meta-micro, ${prefix} is the empty string. This means that CMAKE_INSTALL_BINDIR:PATH and friends end up containing paths starting with many instances of "../", presumably due to os.path.relpath attempting to find its way to the current directory. Let's avoid this by ensuring that the root path always ends in a slash. If it already ends in a slash then adding another one shouldn't cause any problems. (From OE-Core rev: 67b19414c1c17f71f39c971b9f9fdd1f776516a1) Signed-off-by: Mike Crowe Signed-off-by: Richard Purdie