[oe] [RFC][PATCH] cmake: respect ${S} and ${B}
Ross Burton
ross.burton at intel.com
Thu Dec 5 00:38:57 UTC 2013
Hi,
This is a Request For Comments because it changes behaviour of the cmake class
and I'm not entirely knowledgeable in cmake.
For some reason, cmake.bbclass doesn't use ${S} and ${B}, but instead has it's
own variables OECMAKE_SOURCEPATH ("." by default) and OECMAKE_BUILDPATH ("" by
default). Those defaults meant that the build happened in the source directory,
which conveniently was ${S}. Unless ${B} was also set, in which case it all
broke.
I don't see a good reason for cmake.bbclass having it's own special versions of
${S} and ${B}, so this patch drops them and replicates some of the logic in
autotools.bbclass: specifically the part where if ${S} and ${B} are different,
delete ${B} before building. This ensures that switching machine doesn't re-use
the same build directory, which was the cause of me going back to look at this
(libproxy trying to use the nuc sysroot when I'm building for qemux86-64).
Some open questions:
1) As I understand it cmake has more reliable support for out-of-tree builds
than autotools. If this is the case should cmake.bbclass set B ?=
"${WORKDIR}/build", or leave setting of B to separatebuilddir.inc? Are there
known recipes using cmake that fail with out-of-tree builds?
2) Is dropping OECMAKE_SOURCEPATH and OECMAKE_BUILDPATH acceptable? Nothing in
oe-core uses them and there's three (IIRC) recipes in meta-oe that use them.
Assuming the answer to (1) is "separatebuilddir.inc" then the only fallout
should be these recipes using in-tree builds until OECMAKE_BUILDPATH is replaced
with B.
Feedback and testing from people who actively use cmake very welcome.
Cheers,
Ross
More information about the Openembedded-devel
mailing list