All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org,
	openembedded-devel@lists.openembedded.org
Subject: Re: [RFC][PATCH] cmake: respect ${S} and ${B}
Date: Thu, 5 Dec 2013 12:34:03 +0100	[thread overview]
Message-ID: <20131205113403.GC3724@jama> (raw)
In-Reply-To: <1386238202.25847.14.camel@ted>

[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]

On Thu, Dec 05, 2013 at 10:10:02AM +0000, Richard Purdie wrote:
> On Thu, 2013-12-05 at 00:38 +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.
> > 
> > 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?
> 
> separatebuilddir.inc was really a stopgap solution to see how widespread
> potential issues were. Ideally I'd like to get to the point where
> recipes flag themselves are broken with out of tree builds rather than
> having a list of ones which are compatible.
> 
> Doing this for OE-Core is straightforward now but what about meta-oe?
> 
> Would there be interest in trying to change that default or is it going
> to be too painful?

It would be nice to change it in smaller steps, e.g. by bbclasses.

I'm already using separate B by default in meta-qt5 and it works good.

Adding it in cmake, qmake4, then autotools.bbclass, then ... would allow
to fix meta-oe recipes in smaller chunks instead of trying to fix them
all at once. And if we change it only for few .bbclasses then it would
still be improvement.

> This means I'm in favour of changing the cmake default if we can, it
> looks like a simpler problem space than autotools.bbclass

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core@lists.openembedded.org,
	openembedded-devel@lists.openembedded.org
Subject: Re: [OE-core] [RFC][PATCH] cmake: respect ${S} and ${B}
Date: Thu, 5 Dec 2013 12:34:03 +0100	[thread overview]
Message-ID: <20131205113403.GC3724@jama> (raw)
In-Reply-To: <1386238202.25847.14.camel@ted>

[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]

On Thu, Dec 05, 2013 at 10:10:02AM +0000, Richard Purdie wrote:
> On Thu, 2013-12-05 at 00:38 +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.
> > 
> > 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?
> 
> separatebuilddir.inc was really a stopgap solution to see how widespread
> potential issues were. Ideally I'd like to get to the point where
> recipes flag themselves are broken with out of tree builds rather than
> having a list of ones which are compatible.
> 
> Doing this for OE-Core is straightforward now but what about meta-oe?
> 
> Would there be interest in trying to change that default or is it going
> to be too painful?

It would be nice to change it in smaller steps, e.g. by bbclasses.

I'm already using separate B by default in meta-qt5 and it works good.

Adding it in cmake, qmake4, then autotools.bbclass, then ... would allow
to fix meta-oe recipes in smaller chunks instead of trying to fix them
all at once. And if we change it only for few .bbclasses then it would
still be improvement.

> This means I'm in favour of changing the cmake default if we can, it
> looks like a simpler problem space than autotools.bbclass

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

  reply	other threads:[~2013-12-05 11:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05  0:38 [RFC][PATCH] cmake: respect ${S} and ${B} Ross Burton
2013-12-05  0:38 ` [PATCH] " Ross Burton
2013-12-05 22:18   ` Philip Balister
2013-12-05 22:18     ` [OE-core] " Philip Balister
2013-12-05 22:23     ` Richard Purdie
2013-12-05 22:23       ` [OE-core] " Richard Purdie
2013-12-05  0:55 ` [RFC][PATCH] " Martin Jansa
2013-12-05  0:55   ` [OE-core] " Martin Jansa
2013-12-05  9:47   ` Stefan Herbrechtsmeier
2013-12-05 10:03     ` Burton, Ross
2013-12-05  9:43 ` Koen Kooi
2013-12-05 10:10 ` Richard Purdie
2013-12-05 10:10   ` [OE-core] " Richard Purdie
2013-12-05 11:34   ` Martin Jansa [this message]
2013-12-05 11:34     ` Martin Jansa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131205113403.GC3724@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.