Re: [OE-core] [RFC][PATCH] cmake: respect ${S} and ${B}

[Stefan Herbrechtsmeier <stefan@herbrechtsmeier.net>]

Am 05.12.2013 01:55, schrieb Martin Jansa:
> On Thu, Dec 05, 2013 at 12:38:57AM +0000, Ross Burton wrote:
>> Hi,
>>
>> This is a Request For Comments because it changes behaviour of the cmake class
>> and I'm not entirely knowledgeable in cmake.
> Neither am I, but patch looks reasonable and I like it, because I was
> planing to do something similar.
Maybe you should add a warning if OECMAKE_BUILDPATH is not "" as 
otherwise the package behaviour will change without any note.

>> 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.
I think deleting ${B} before building is wrong. If the build directory 
makes problem you should have the same problems when ${S} and ${B} are 
same or you should remove the ${B} directories when you remove the build 
files from ${S}.

>>   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.
As you more or less only rename the variables it should be acceptable 
but I would proposed to add a warning or error if some recipe use the 
old variables.