From mboxrd@z Thu Jan 1 00:00:00 1970 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 1QPOyT-0000Rx-OJ for openembedded-core@lists.openembedded.org; Thu, 26 May 2011 03:02:54 +0200 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id p4Q0xpQh007260 for ; Thu, 26 May 2011 01:59:51 +0100 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 06726-09 for ; Thu, 26 May 2011 01:59:47 +0100 (BST) 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 p4Q0xj2L007254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 May 2011 01:59:45 +0100 From: Richard Purdie To: Patches and discussions about the oe-core layer In-Reply-To: References: <1306342881.2525.258.camel@phil-desktop> <1306364520.27470.81.camel@rex> <1306368023.27470.91.camel@rex> Date: Thu, 26 May 2011 01:59:43 +0100 Message-ID: <1306371583.27470.96.camel@rex> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 X-Virus-Scanned: amavisd-new at rpsys.net Subject: Re: RDEPENDS_${PN} and virtclass-native 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: Thu, 26 May 2011 01:02:54 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Wed, 2011-05-25 at 17:11 -0700, Chris Larson wrote: > On Wed, May 25, 2011 at 5:00 PM, Richard Purdie > wrote: > > On Thu, 2011-05-26 at 00:02 +0100, Richard Purdie wrote: > >> I think we need to fix native.bbclass. I dread to think what this is > >> doing to the dependency tree at present. We did remove most references > >> to RDEPENDS directly so I think that makes this a high priority to fix. > >> > >> I'd note that the rewriting code is fraught with ordering/expansion > >> issues which is why that code plays games with the variables like it > >> does. > >> > >> DEPENDS is horrible and it looks like we needed to do something similar > >> for RDEPENDS. Better solutions to the ordering problems would be very > >> welcome. It problem was the use of DEPENDS_prepend in places iirc. > > > > I just reminded myself of the problem with DEPENDS. > > > > Imagine the recipe says: > > > > DEPENDS = "foo" > > inherit autotools > > > > Behind the scenes, autotools (amongst other thinsg) does a: > > > > DEPENDS_prepend = "autoconf-native" > > > > The trouble comes when you try: > > > > DEPENDS_virtclass-native = "" > > > > since you want to drop the foo dependency. The dependencies being added > > by autotools.bbclass are still wanted but they get overwritten. At this > > point I had to remember bitbake's finalize ordering. It does: > > > > finalize() > > > > finalize() > > > > The first call to finalize() expands the _prepend/_append before we see > > them. We then lose the ability to see what was added though the classes > > vs. what was in the recipe. The second finalize can then only clobber > > the data. > > > > If we could get our function called before the first finalize(), we > > would remove the need to play the games we do which is looking very very > > attractive. > > > > I suspect its time to extend the anonymous python to indicate more > > specifically when it would like to be run... > > Just need to add another event at the appropriate place. I wonder > where RecipeParsed fits into that ordering. Of course its not that simple. I just discovered: OVERRIDES = "z" DEPENDS_prepend = "a " DEPENDS = "b" DEPENDS_z = "c" d.update_data() d.getVar("DEPENDS") gives "a c" d.update_data() d.getVar("DEPENDS") gives "c" since the _prepend is lost after the update_data(), the _z override is not and so the second call overwrites all of DEPENDS. We've talked before how overrides should really renameVar, not just copy contents. Obviously there are a lot of subtleties to this though and we can't just switch due to backwards compatibility :/ Depending on the number of update_data() calls is truly horrible behaviour though :( Cheers, Richard