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

cmake.bbclass: use `cmake --build` to build & install

2017-05-23T16:45:36+00:00

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 (From OE-Core rev: 2b06cb961edbe52ff66e8edccd007edd0795c30b) Signed-off-by: Cody P Schafer Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

cmake.bbclass: remove unneded cd ${B}

2017-05-16T13:08:28+00:00

The default dir for do_compile & do_configure is already ${B}, no need to cd (other than broken appends) CC: Andre McCurdy (From OE-Core rev: c5da7a3637b0eb8ec5b7368c7ac732d802a703f9) Signed-off-by: Cody P Schafer Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

cmake.bbclass: use weakest ??= assignment for default OECMAKE_SOURCEPATH

2017-04-29T10:17:23+00:00

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 Signed-off-by: Richard Purdie

cmake.bbclass: Do not use bitbake variable syntax for shell variables

2017-04-29T10:17:22+00:00

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 Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

cmake.bbclass: Set CMAKE_CROSSCOMPILING correctly

2017-04-19T09:18:43+00:00

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 Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T10:23:23+00:00

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 Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

cmake.bbclass: Set CXXFLAGS and CFLAGS

2016-11-23T11:10:12+00:00

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 Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/externalsrc: re-run do_configure when configure files change

2016-10-11T22:04:44+00:00

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 Signed-off-by: Richard Purdie

cmake.bbclass: avoid treating imports as system includes

2016-09-07T23:32:43+00:00

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 Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

cmake.bbclass: call cmake with a relative path

2016-08-23T16:44:42+00:00

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 Signed-off-by: Clemens Lang Signed-off-by: Ross Burton Signed-off-by: Richard Purdie