Received: from 93-97-173-237.zone5.bethere.co.uk ([93.97.173.237] helo=tim.rpsys.net) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1S0uoe-0001P0-FT for openembedded-core@lists.openembedded.org; Fri, 24 Feb 2012 14:04:04 +0100 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id q1OCtglk006071 for ; Fri, 24 Feb 2012 12:55:42 GMT Received: from tim.rpsys.net ([127.0.0.1]) by localhost (tim.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05627-03 for ; Fri, 24 Feb 2012 12:55:38 +0000 (GMT) Received: from [192.168.3.10] ([192.168.3.10]) (authenticated bits=0) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id q1OCtYr6006065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 24 Feb 2012 12:55:35 GMT Message-ID: <1330088135.32006.14.camel@ted> From: Richard Purdie To: openembedded-core Date: Fri, 24 Feb 2012 12:55:35 +0000 X-Mailer: Evolution 3.2.2- Mime-Version: 1.0 X-Virus-Scanned: amavisd-new at rpsys.net Subject: Using external source trees with OE-Core X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 13:04:04 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Someone recently asked me about using external source trees with OE-Core. I was aware of srctree.bbclass in OE-Classic and did start looking at it but it has various elements I wasn't so keen on. I therefore wondered if I could improve upon it. I did start from that code base but came up with: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/a0&id=ac8a54c18c33aaab6758c34a3d6093d3d3384cee [patch inline below] which I've called externalsrc.bbclass since it behaves a bit differently. In particular, all the usual task targets are available. As an example usage with the above patch applied: cd ~ tar -xvzf $DL_DIR/libfm-0.1.17.tar.gz (creates libfm-0.1.17 in my homedir) edit libfm_0.1.17.bb and add: inherit externalsrc S = "/home/richard/libfm-0.1.17" bitbake libfm and it does what you'd expect. You can also -c clean and it will wipe out WORKDIR but it won't touch ${S}. I picked libfm effectively at random. It won't remove the autoreconf changes from configure but I'm not sure I care much about that. Admittedly, I did have to fix one Makefile.am which did '-I../' instead of "-I$(srcdir)/../" but that is a bug in libfm. Obviously this won't work quite as well with some recipes like linux-yocto which manipulate ${S} a lot more but it should work in most cases. I also found it very hard to remove tasks from the anonymous python, we probably need to improve the API for this. Opinions on including this class? Cheers, Richard From ac8a54c18c33aaab6758c34a3d6093d3d3384cee Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Fri, 24 Feb 2012 12:29:36 +0000 Subject: externalsrc.bbclass: Add class for handling external source trees This is loosly based upon srctree.bbclass from OE-Classic but with some changes appropriate to OE-Core. Signed-off-by: Richard Purdie --- diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass new file mode 100644 index 0000000..7e00ef8 --- a/dev/null +++ b/meta/classes/externalsrc.bbclass @@ -0,0 +1,53 @@ +# Copyright (C) 2012 Linux Foundation +# Author: Richard Purdie +# Some code and influence taken from srctree.bbclass: +# Copyright (C) 2009 Chris Larson +# Released under the MIT license (see COPYING.MIT for the terms) +# +# externalsrc.bbclass enables use of an existing source tree, usually external to +# the build system to build a piece of software rather than the usual fetch/unpack/patch +# process. +# +# To use, set S to point at the directory you want to use containing the sources +# e.g. S = "/path/to/my/source/tree" +# +# If the class is to work for both target and native versions (or with multilibs/ +# cross or other BBCLASSEXTEND variants), its expected that setting B to point to +# where to place the compiled binaries will work (split source and build directories). +# This is the default but B can be set to S if circumstaces dictate. +# + +SRC_URI = "" +SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch" +B = "${WORKDIR}/${BPN}-${PV}/" + +def remove_tasks(tasks, deltasks, d): + for task in tasks: + deps = d.getVarFlag(task, "deps") + for preptask in deltasks: + if preptask in deps: + deps.remove(preptask) + d.setVarFlag(task, "deps", deps) + # Poking around bitbake internal variables is evil but there appears to be no better way :( + tasklist = d.getVar('__BBTASKS') or [] + for task in deltasks: + d.delVarFlag(task, "task") + if task in tasklist: + tasklist.remove(task) + d.setVar('__BBTASKS', tasklist) + +python () { + tasks = filter(lambda k: d.getVarFlag(k, "task"), d.keys()) + covered = d.getVar("SRCTREECOVEREDTASKS", True).split() + + for task in tasks: + if task.endswith("_setscene"): + # sstate is never going to work for external source trees, disable it + covered.append(task) + else: + # Since configure will likely touch ${S}, ensure only we lock so one task has access at a time + d.appendVarFlag(task, "lockfiles", "${S}/singletask.lock") + + remove_tasks(tasks, covered, d) +} +