summaryrefslogtreecommitdiffstats
path: root/meta/classes/cmake.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* cmake.bbclass: remove ${B} before cmake_do_configureKai Kang2021-04-241-5/+3
| | | | | | | | | | | | 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 <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: Fully-qualified path to arDouglas Royds2021-03-201-1/+2
| | | | | | | | | | | | | | 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 <douglas.royds@taitradio.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: Create cmake arch mapping for ppc64leKhem Raj2021-03-141-0/+2
| | | | | | | (From OE-Core rev: 698ece14e22d0efd9074493ef443b2cce5625d51) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: set CMAKE_EXPORT_NO_PACKAGE_REGISTRYKonrad Weihmann2021-02-191-0/+1
| | | | | | | | | | | | | if a cmake file uses export(PACKAGE) command it creates a folder ~/.cmake/package/<name> 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 <kweihmann@outlook.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: Rework compiler program variables for allarchNathan Rossi2020-08-101-19/+17
| | | | | | | | | | | | | | | | | 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 <nathan@nathanrossi.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/cmake: Fix host detectionJoshua Watt2020-07-221-6/+13
| | | | | | | | | | | | | | | | | | 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 <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: fix Python executable with cmakeMartin Kelly2020-04-051-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mkelly@xevo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: prefer CMAKE_BUILD_PARALLEL_LEVELDaniel McGregor2020-02-041-2/+3
| | | | | | | | | | | | 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 <daniel.mcgregor@vecima.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: Define LIB_SUFFIXKhem Raj2019-12-301-0/+1
| | | | | | | | | | | | | 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 <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: Add a knob for cmake VERBOSE settingsKhem Raj2019-12-301-2/+11
| | | | | | | | | | | | | | | | | | | | | | 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 <raj.khem@gmail.com> Cc: Ross Burton <ross.burton@intel.com> Cc: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/cmake: Use relative RPATHsJoshua Watt2019-11-271-0/+3
| | | | | | | | | | | | | | | | 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 <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: add HOSTTOOLS_DIR to CMAKE_FIND_ROOT_PATHMichael Ho2019-10-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | 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 <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: Clarify comment in cmake toolchain fileuninative-2.6Richard Purdie2019-06-201-1/+1
| | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* cmake: Avoid passing empty prefix to os.path.relpathMike Crowe2019-06-121-7/+7
| | | | | | | | | | | | | | | | 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 <mac@mcrowe.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: Use compiler launcher variable when ccache is enabledPhilippe Normand2019-05-301-2/+9
| | | | | | | | | | | Setting the CMAKE_C{,XX}_COMPILER_LAUNCHER variables is the recomended way to deal with ccache in CMake. It allows build scripts to optionally opt-out of ccache, which is especially useful when the pre-processed GCC output is required. (From OE-Core rev: 0a36d1b342c0b4760bc75794c2e941a17012bc19) Signed-off-by: Philippe Normand <philn@igalia.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: Support Eclipse and other cmake generatorsNikhil Pal Singh2019-04-101-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support project-file generators such as CodeBlocks, CodeLite, Eclipse, Sublime, and Kate for both make and Ninja build systems. The following generators are listed in cmake --help: Unix Makefiles = Generates standard UNIX makefiles. Ninja = Generates build.ninja files. Watcom WMake = Generates Watcom WMake makefiles. CodeBlocks - Ninja = Generates CodeBlocks project files. CodeBlocks - Unix Makefiles = Generates CodeBlocks project files. CodeLite - Ninja = Generates CodeLite project files. CodeLite - Unix Makefiles = Generates CodeLite project files. Sublime Text 2 - Ninja = Generates Sublime Text 2 project files. Sublime Text 2 - Unix Makefiles = Generates Sublime Text 2 project files. Kate - Ninja = Generates Kate project files. Kate - Unix Makefiles = Generates Kate project files. Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files. Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files. All but one of these contain one of the strings, "Unix Makefiles" or "Ninja". In each of these cases, cmake generates the Makefiles (or ninja files respectively), and also the appropriate project files, eg. .project and .cproject for Eclipse. A user can set OECMAKE_GENERATOR in their local.conf to any one of these strings, except "Watcom WMake" (not supported). (From OE-Core rev: 256e8b5deae66b1463c359db12af396702912139) Signed-off-by: Nikhil Pal Singh <nikhilpal.singh@taitradio.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: Reduce verbosity for make invocationDouglas Royds2019-03-121-1/+0
| | | | | | | | | | | | | | | | | Since the dawn of time, we have set CMAKE_VERBOSE_MAKEFILE=1 in cmake.bbclass. Back in 2016, we also explicitly set VERBOSE=1 in cmake_do_compile(), to ensure that make (and ninja) output were verbose in log.do_compile. Turning off CMAKE_VERBOSE_MAKEFILE=1 means that make (or ninja) invocations from the command-line are non-verbose, giving CMake's default human-readable output on the terminal instead. The user can still invoke VERBOSE=1 make if they do want verbose output. This has no effect on the verbose output that goes into the logs. (From OE-Core rev: 75c4b61513d8b089e835fb8d5923d8749fed7880) Signed-off-by: Douglas Royds <douglas.royds@taitradio.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: Make it work with ccacheRobert Yang2019-01-141-6/+15
| | | | | | | | | | | | | | | | This can make the following recipes work with cmake: cmake libdnf libcomps librepo createrepo-c llvm dnf libsolv assimp waffle libjpeg-turbo taglib libproxy libical And the following 3 recipes don't: webkitgtk vulkan piglit Now cmake.bbclass doesn't disble ccache any more, disable it in the recipes if needed. (From OE-Core rev: d014c8c11fb663f131d3a860ddeda17d604b2dd3) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: append includedir to implicit include dirsMichael Ho2018-12-141-0/+4
| | | | | | | | | | | | | This resolves issues with paths being marked as system includes that differ from /usr/include but are considered implicit by the toolchain. This enables developers to add directories to system includes to supress compiler compiler warnings from them. (From OE-Core rev: 9c2227d5d960f93e00791157354f0c920fbecf39) Signed-off-by: Michael Ho <Michael.Ho@bmw.de> Cc: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes: Correctly markup regex stringsRichard Purdie2018-12-081-1/+1
| | | | | | | | | There are various escape characters in these stings which python warns about so use the correct regex markup for them. (From OE-Core rev: 252b69c9f2abe3258366c540f56b156ed63e5437) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: handle cmake -dev files packaging with default rulesAndre McCurdy2018-06-281-2/+0
| | | | | | | | | | | Move packaging rules for cmake -dev files from cmake.bbclass into bitbake.conf to handle recipes (e.g. harfbuzz 1.8.1) which build with autotools but also install cmake -dev files. (From OE-Core rev: 543e39ad5e2baa0f1ece013a89483783e6b15dd9) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: refactor compile and install for easier re-useAndré Draszik2018-03-041-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | cmake_do_compile() and cmake_do_install() basically do the same, except they use a different --target, and at the moment this is copy/pasted code with a minor modification. Other recipes which e.g. might want to support compilation as part of ptest have to do the same. This is a bit inconvenient. By factoring out all of this into a common helper, cmake_runcmake_build(), this is easily re-used. An (imaginary) recipe can compile ptest support simply by using cmake_runcmake_build --target buildtest-TESTS (assuming such a build target exists). Also, this now is very similar to oe_runmake(). (From OE-Core rev: 7620dafe7358f017a8cd558b480af73896768f04) Signed-off-by: André Draszik <andre.draszik@jci.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: use Ninja by defaultRoss Burton2018-01-191-1/+1
| | | | | | | | | | | | This changes the cmake class to use Ninja instead of Make by default. If a recipe is broken with Ninja then the recipe can set OECMAKE_GENERATOR="Unix Makefiles" to change back to Make. (From OE-Core rev: bacaa26decb8a1e3fa672e1923954793fde48766) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: allow the generator to be changedRoss Burton2018-01-191-2/+18
| | | | | | | | | | | | Add OECMAKE_GENERATOR variable to control which generator is used by CMake, defaulting to the upstream default of Unix Makefiles for now. The other supported option is Ninja, which is faster than Make for large projects (for example, using Ninja takes three minutes off webkitgtk:do_compile for me). (From OE-Core rev: 6e3f719076cab469f56cd1555bd219a5c3fd135d) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: upgrade 3.9.5 -> 3.10.1Otavio Salvador2018-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The 3.10.1 version has been in Dec 13, 2017, and has a great set of features and improvements since the last upgrade. The release notes of 3.10 release is available at: https://cmake.org/cmake/help/v3.10/release/3.10.html Patches updates: - cmake-Prevent-the-detection-of-Qt5.patch: so it replaces the sed command calls inside the cmake.inc - 0001-FindCUDA-Use-find_program-if-find_host_program-is-no.patch: merged upstream, so it has been removed. - support-oe-qt4-tools-names.patch: rebased. License-checksum-change: added new contributors (From OE-Core rev: 9e58926f1cea9d5cb18cb923855d1ae98f88a8ac) Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: allow target names to be overriddenRoss Burton2018-01-181-4/+7
| | | | | | | | | | | Don't hardcode the targets used in do_compile and do_install, instead build "all" and "install" by default but respect OECMAKE_TARGET_COMPILE and OECMAKE_TARGET_INSTALL variables. (From OE-Core rev: 806765ec466597d38231d4be303cb48c26e21466) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: Always put cmake package files in -dev packagesMike Crowe2018-01-071-0/+2
| | | | | | | | | | | | Various recipes that inherit cmake contain FILES_${PN}-dev magic to add the generated package files to their -dev packages. Since this is a standard feature of cmake, we might as well teach cmake.bbclass to do this itself so those recipes can be simpler. (From OE-Core rev: d91dc4666683a96e9d03cbbd21b8a546f9069c93) Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: use `cmake --build` to build & installCody P Schafer2017-05-231-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | Rather than presuming `make` is the generator, use cmake's generic `cmake --build` feature (which knows to call the appropriate generator). Both DESTDIR and VERBOSE still behave as intended when used as environment variables instead of make variable-arguments. As cmake-based builds don't do any configuration with `make` invocations, we only pass `PARALLEL_MAKE{,INST}` (via a EXTRA_OECMAKE_BUILD variable) to the underlying build tool. Make & ninja support the same `-j N` option (and a few others), so this does happen to work for both. This makes it more straight forward for others to select other cmake generators (many folks have been reaching for `ninja` lately). CC: Andre McCurdy <armccurdy@gmail.com> (From OE-Core rev: 2b06cb961edbe52ff66e8edccd007edd0795c30b) Signed-off-by: Cody P Schafer <dev@codyps.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: remove unneded cd ${B}Cody P Schafer2017-05-161-2/+0
| | | | | | | | | | | | The default dir for do_compile & do_configure is already ${B}, no need to cd (other than broken appends) CC: Andre McCurdy <armccurdy@gmail.com> (From OE-Core rev: c5da7a3637b0eb8ec5b7368c7ac732d802a703f9) Signed-off-by: Cody P Schafer <dev@codyps.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: use weakest ??= assignment for default OECMAKE_SOURCEPATHAndre McCurdy2017-04-291-1/+1
| | | | | | | | | | Make it slightly easier to support situations where the default path needs to be over-ridden more than once. (From OE-Core rev: 07390e3d45cdf244079a6b91175512ebac789da0) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: Do not use bitbake variable syntax for shell variablesPeter Kjellerstedt2017-04-291-5/+5
| | | | | | | | | | | | | | | Using bitbake variable syntax (i.e., ${FOO}) for shell variables is bad practice. First of all it is confusing, but more importantly it can lead to weird problems if someone actually defines a bitbake variable with the same name as the shell variable. Also use lower case for local shell variables. (From OE-Core rev: ea6befae799f45cf93771442f242cb023dd809d1) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: Set CMAKE_CROSSCOMPILING correctlyKyle Russell2017-04-191-0/+4
| | | | | | | | | | | If CMAKE_SYSTEM_NAME is defined, CMake assumes we're cross-compiling, which is not necessarily the case. (From OE-Core rev: bd082c9be6191e67ea1b1bf10ce5e130a3433ab5) Signed-off-by: Kyle Russell <bkylerussell@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: remove True option to getVar callsJoshua Lock2016-12-161-8/+8
| | | | | | | | | | | | | getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: Set CXXFLAGS and CFLAGSKhem Raj2016-11-231-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We strip the TOOLCHAIN_OPTIONS and HOST_CC_ARCH from CC/CXX in cmake.bbclass whereas CFLAFS and CXXFLAGS assume that TOOLCHAIN_OPTIONS are part of CC/CXX variables, this causes compile failures when cmake is running compiler tests during configure on some architectures especially armhf, because hf ABI information -mfloat-abi is part of TOOLCHAIN_OPTIONS, so what happens is that testcase gets compiled without hard-float, howver, during linking the float ABI option is passed via LDFLAGS, now linker rejects this and fails like /mnt/a/build/tmp-glibc/sysroots/x86_64-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/6.2.0/ld: error: cmTC_27947 uses VFP register arguments, CMakeFiles/cmTC_27947.dir/src.cxx.o does not mnt/a/build/tmp-glibc/sysroots/x86_64-linux/usr/libexec/arm-oe-linux-gnueabi/gcc/arm-oe-linux-gnueabi/6.2.0/ld: failed to merge target specific data of file CMakeFiles/cmTC_27947.dir/src.cxx.o collect2: error: ld returned 1 exit status This means that CMake now fails the configure time test too which is not right, e.g. it might disable features which actually do exist and should be enabled e.g. in case above it is resulting as below Performing C++ SOURCE FILE Test HAS_BUILTIN_SYNC_SUB_AND_FETCH failed with the following output: Its actually a bug in CMake see https://gitlab.kitware.com/cmake/cmake/issues/16421 CMake is ignoring CMAKE_CXX_FLAGS when using CHECK_CXX_SOURCE_COMPILES function. Until it is fixed upstream, we add HOST_CC_ARCH and TOOLCHAIN_OPTIONS to CFLAGS and CXXFLAGS, so that we can ensure that compiler invocation remains consistent. (From OE-Core rev: 826f3cdb474b5728b22f08d2342fc90235ca9e7d) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/externalsrc: re-run do_configure when configure files changePaul Eggleton2016-10-111-0/+2
| | | | | | | | | | | | | | | | | | If the user modifies files such as CMakeLists.txt in the case of cmake, we want do_configure to re-run so that those changes can take effect. In order to accomplish that, have a variable CONFIGURE_FILES which specifies a list of files that will be put into do_configure's checksum (either full paths, or just filenames which will be searched for in the entire source tree). CONFIGURE_FILES then just needs to be set appropriately depending on what do_configure is doing; for now I've set this for autotools and cmake which are the most common cases. Fixes [YOCTO #7617]. (From OE-Core rev: 923fc20c2862a6d75f949082c9f6532ab7e2d2cd) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: avoid treating imports as system includesAndreas Müller2016-09-081-0/+1
| | | | | | | | | | | | | | | | | CMake sets all imported headers as system headers. This causes trouble for c++ projects [1]. Thanks to Jack Mitchell for pointing to the setting [2]. Build tested upon meta-qt5-extra-world which had lots of fallout before. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129 [2] http://lists.openembedded.org/pipermail/openembedded-core/2016-September/126067.html (From OE-Core rev: a5bf690e27a32c5470a4e110ab58ed0a92b9d039) Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: call cmake with a relative pathThomas Witt2016-08-231-7/+7
| | | | | | | | | | | | | | | | | | CMake wants a relative path for CMAKE_INSTALL_*DIR, an absolute path breaks cross-compilation. This fact is documented in the following ticket: https://cmake.org/Bug/view.php?id=14367 $sysconfdir and $localstatedir are not relative to $prefix, so they are still set as absolute paths. With his change ${PROJECT}Targets.cmake that are generated by cmakes "export" function will contain relative paths instead of absolute ones. (From OE-Core rev: c03b32bd71dbe04f2f239556fea0b53215e403d7) Signed-off-by: Thomas Witt <Thomas.Witt@bmw.de> Signed-off-by: Clemens Lang <clemens.lang@bmw-carit.de> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/cmake: enable progress for do_compilePaul Eggleton2016-07-081-0/+1
| | | | | | | | | | cmake outputs percentage complete as part of its compilation process, so we can enable BitBake's new progress scanning for do_compile here. (From OE-Core rev: f77ea95ba5cd337f01f2a1b4fe9466feb6af9440) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Revert "cmake.bbclass: set the modules directory correctly"Richard Purdie2016-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 642bd49964690259328f506df41a1764c5ac6226. This broke "bitbake cmake": | CMake Error at /home/jku/src/poky/build/tmp/work/core2-64-poky-linux/cmake/3.5.2-r0/toolchain.cmake:34 (list): | Syntax error in cmake code at | | /home/jku/src/poky/build/tmp/work/core2-64-poky-linux/cmake/3.5.2-r0/toolchain.cmake:34 | | when parsing string | | /home/jku/src/poky/build/tmp/sysroots/qemux86-64/usr/share/cmake-\3.5.${CMAKE_MINOR_VERSION}/Modules/ | | Invalid character escape '\3'. | Call Stack (most recent call first): | /home/jku/src/poky/build/tmp/sysroots/x86_64-linux/usr/share/cmake-3.5/Modules/CMakeDetermineSystem.cmake:98 (include) | CMakeLists.txt:19 (project) https://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/832 https://autobuilder.yoctoproject.org/main/builders/nightly-world-lsb/builds/550 Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: set the modules directory correctlyJose Pardeiro2016-06-171-1/+1
| | | | | | | | | | | | The CMake recipes contain a mismatch between the environmental variable which defines where the Modules are installed and the location where they actually are. This patch fixes the environmental variable to point to the proper folder defined according to the cmake version. (From OE-Core rev: 642bd49964690259328f506df41a1764c5ac6226) Signed-off-by: Jose Pardeiro <jpardeiro@rapyuta-robotics.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: enable verbose buildsRoss Burton2016-05-141-1/+1
| | | | | | | | | | To help debugging build problems pass VERBOSE=1 to make so that the makefiles print their commands, just like we do with autotools. (From OE-Core rev: 62f95a769ec9e11c72fbf78257badbfb59f1b354) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* base.bbclass: Introduce PACKAGECONFIG_CONFARGS variableMartin Jansa2016-04-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | * add separate variable for configuration options generated from PACKAGECONFIG setting, this helps other bbclasses and recipes to take advantage of PACKAGECONFIG mechanism, without including other options from EXTRA_OECONF * e.g. meta-qt5 recipes are abusing EXTRA_OECONF to get options from PACKAGECONFIG: EXTRA_QMAKEVARS_PRE += but with conf/distro/include/no-static-libs.inc it means getting --disable-static as invalid option inside EXTRA_QMAKEVARS_PRE as reported by Alexandre Belloni who tried to use poky with meta-qt5. * once we migrate all bbclasses and recipes to PACKAGECONFIG_CONFARGS we should also restrict EXTRA_OECONF append only to autotools.bbclass like I did for cmake.bbclass (From OE-Core rev: 0ea4a47bfc27d02594d489b27c029d3d3badf3d4) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: don't inherit autotoolsRoss Burton2016-02-181-4/+1
| | | | | | | | | | | autotools was inherited for some functions some time ago, but now all it's using it for explicitly is autotools_do_install(), which is basically just "make install". Invoke that directly and we can remove the inherit autotools. (From OE-Core rev: 1cbc0400621c23243d96dedf4a226a732f5c87c9) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: don't duplicate CMAKE_C_FLAGS in CMAKE_C_FLAGS_RELEASEAndre McCurdy2015-11-161-5/+5
| | | | | | | | | | | | | | The base CMAKE_<LANG>_FLAGS are included for all build types, therefore the CMAKE_<LANG>_FLAGS_RELEASE should contain only additional flags or over-rides. https://cmake.org/cmake/help/v3.2/variable/CMAKE_LANG_FLAGS.html (From OE-Core rev: 961740d5d81ce44a595d5465bafb48a0cbab5159) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/cmake: add arch conversion routineAlexander Kanavin2015-08-241-1/+11
| | | | | | | | | | | cmake expects target architecture strings in the format of uname(2), which do not always match TARGET_ARCH (e.g. powerpc vs ppc). (From OE-Core rev: 7c61d022aa9bbba3c2f8a2df46eeb19e2772c89a) Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake bbclass: fix support for native buildsKoen Kooi2015-07-021-1/+4
| | | | | | | | | | For native builds of recipes (e.g. mariadb-native) cmake *must* look outside of its sysroot to find the compiler, so instruct it to do so. (From OE-Core rev: 907828acebcf07d7a9367432432d04e0dab283d3) Signed-off-by: Koen Kooi <koen.kooi@linaro.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: extend CMAKE_MODULE_PATH instead of settingRoss Burton2015-06-111-1/+1
| | | | | | | | | | | | Some (e.g. piglit) CMakeList.txt files will extend CMAKE_MODULE_PATH before calling project(), which is when the toolchain.cmake file is parsed. In this situation the CMAKE_MODULE_PATH is overwritten, so handle this by appending in toolchain.cmake instead of assigning. (From OE-Core rev: 2cfa8427d77f680df37c12d00125501ebe7c38a3) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: Whitespace fixMoritz Blume2015-06-081-1/+1
| | | | | | | | (From OE-Core rev: f0d6523302fe1d246833b5d0b2dcfe0c0efd5239) Signed-off-by: Moritz Blume <moritz.blume@bmw-carit.de> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: supply CMAKE_AR in toolchain fileCody P Schafer2014-12-051-0/+2
| | | | | | | (From OE-Core rev: 79144da00f005b5a3ab8f7404730216cfc684616) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: Try and improve cleaning of builds when B==SRichard Purdie2014-10-301-0/+2
| | | | | | | | | | Currently if B==S for a cmake recipe, the build will not reconfigure. This patch adds code to remove the generated cmake files, meaning cmake will then be forced to regenerate them. This forces cmake to see configuration changes it may not otherwise see. (From OE-Core rev: 01f4ed0cfbc60859aabfa5bff33ed966117a05d7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-14 00:28:21 +0000