From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-bk0-f47.google.com ([209.85.214.47]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1S4Zdg-0000y5-5o for bitbake-devel@lists.openembedded.org; Mon, 05 Mar 2012 16:15:52 +0100 Received: by bkcjg15 with SMTP id jg15so3439484bkc.6 for ; Mon, 05 Mar 2012 07:07:17 -0800 (PST) Received-SPF: pass (google.com: domain of sledz@dresearch-fe.de designates 10.204.155.84 as permitted sender) client-ip=10.204.155.84; Authentication-Results: mr.google.com; spf=pass (google.com: domain of sledz@dresearch-fe.de designates 10.204.155.84 as permitted sender) smtp.mail=sledz@dresearch-fe.de Received: from mr.google.com ([10.204.155.84]) by 10.204.155.84 with SMTP id r20mr10700220bkw.35.1330960037804 (num_hops = 1); Mon, 05 Mar 2012 07:07:17 -0800 (PST) Received: by 10.204.155.84 with SMTP id r20mr8487270bkw.35.1330960037585; Mon, 05 Mar 2012 07:07:17 -0800 (PST) Received: from fensuse.internal.dresearch-fe.de (pd95cb174.dip0.t-ipconnect.de. [217.92.177.116]) by mx.google.com with ESMTPS id y9sm26048071bkw.5.2012.03.05.07.07.16 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 07:07:17 -0800 (PST) Message-ID: <4F54D6A4.9080904@dresearch-fe.de> Date: Mon, 05 Mar 2012 16:07:16 +0100 From: Steffen Sledz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Richard Purdie References: <4F4F7D9C.8070300@dresearch-fe.de> <1330954103.17022.15.camel@ted> In-Reply-To: <1330954103.17022.15.camel@ted> X-Enigmail-Version: 1.3.5 X-Gm-Message-State: ALoCoQnbzvNiAOyCsckXs6lxE0U5e7v/WHJQ5Uj5k4ZIA054CSD/n+ANqPNknWsw+H17Z3nSdcEq X-Mailman-Approved-At: Mon, 05 Mar 2012 19:30:14 +0100 Cc: bitbake-devel@lists.openembedded.org, openembedded-devel Subject: Re: bitbake dependency cache problem X-BeenThere: bitbake-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:15:52 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05.03.2012 14:28, Richard Purdie wrote: > On Thu, 2012-03-01 at 14:46 +0100, Steffen Sledz wrote: >> I'm working with oe-classic and BitBake Build Tool Core version >> 1.12.0, bitbake version 1.12.0. >> >> Because of some special development requirements we like to generate >> the Package Version from the SVN Revision (not the Last Changed Rev!) >> of the bitbake recipe in the local workspace. >> >> Therefor the recipe contains this: >> >> ---------------->snip<----------------- >> PR = "r8" >> PV = "svnr${@svn_revision(d)}" >> >> inherit svn-helper >> ---------------->snip<----------------- >> >> The svn-helper.bbclass contains a little helper function to determine >> the needed value: >> >> ---------------->snip<----------------- >> def svn_revision(d): >> import subprocess >> bbpath = os.path.dirname(bb.data.getVar('FILE',d,1)) >> return subprocess.check_output(["svn", "info", bbpath]).partition("Revision: ")[2].splitlines()[0] >> ---------------->snip<----------------- >> >> After this changes i make a first build and everything works fine. >> Assuming the SVN Revsion is 42 a package called foo-svnr42-r8.ipk is >> generated. >> >> Now i make an "svn update" inside the workspace and the SVN Revision >> increases to 66. >> >> A call of "bitbake foo" now results in an "Tasks Summary: Attempted >> 1182 tasks of which 1182 didn't need to be rerun and 0 failed." an no >> new ipg is generated. :( >> >> The log generated by "bitbake -DDDDDvvvvv foo" contains >> >> ---------------->snip<----------------- >> DEBUG: providers for foo are: ['foo'] >> NOTE: checking PREFERRED_PROVIDER_foo >> NOTE: checking PREFERRED_PROVIDER_foo-svnr42 >> NOTE: checking PREFERRED_PROVIDER_foo-svnr42-r8 >> ---------------->snip<----------------- >> >> Why does bitbake not respects the new PV and generates a >> foo-svnr66-r8.ipk here??? > > Bitbake has no idea that the PV has changed and that it needs to ignore > the cache value and reparse the metadata for that file. The similar > example is when autorev is used with a source control system. You can > can see the code for this in lib/bb/fetch2/__init__.py in get_autorev(). > In summary, if you set __BB_DONT_CACHE = "1" in your recipe, I think it > will do what you expect, at the cost that it will reparse the recipe > every time (which it has to in case PV changes). This solution seems to work. :) Thx, Steffen -- DResearch Fahrzeugelektronik GmbH Otto-Schmirgal-Str. 3, 10319 Berlin, Germany Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de Fax: +49 30 515932-299 Geschäftsführer: Dr. Michael Weber, Werner Mögle; Amtsgericht Berlin Charlottenburg; HRB 130120 B; Ust.-IDNr. DE273952058