[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