[yocto] One question about taskdata and runqueue

Xu, Dongxiao dongxiao.xu at intel.com
Mon Feb 27 18:21:00 PST 2012


On Mon, 2012-02-27 at 16:19 +0000, Richard Purdie wrote:
> On Mon, 2012-02-27 at 21:51 +0800, Xu, Dongxiao wrote:
> > Hi list,
> > 
> > If I have two recipes, see following. Both of them provides
> > "virtual/test" and has package named "test-test", the only difference is
> > the RDEPENDS of the package "test-test".
> > 
> > test-a_1.0.bb
> > 
> > PROVIDES = "virtual/test"
> > PACKAGES = "test-test"
> > # Assume that the abcd package are provided by recipe abcd.bb
> > RDEPENDS_test-test = "abcd"
> > 
> > 
> > test-b_1.0.bb
> > 
> > PROVIDES = "virtual/test"
> > PACKAGES = "test-test"
> > 
> > In a certain configuration file, we have the PREFERRED_PROVIDER set as:
> > PREFERRED_PROVIDER_virtual/test = "test-a".
> > 
> > Then if a real recipe, for example, the 'v86d', depends on the
> > "virtual/test":
> > DEPENDS = "virtual/test"
> > 
> > Finally if I run the following command:
> > # bitbake v86d
> > 
> > We know that the recipe "abcd" will be included in the runqueue.
> > 
> > My question is, can we get the build dependency to recipe "abcd" through
> > taskdata? Or it is finalized until we create the RunQueue object?
> 
> task data should have a list of providers for "virtual/test", sorted in
> priority order. There should be two entries in that list, one for test-a
> and test-b. Since you set the preferred provider, you should have test-a
> as the first item.
> 
> Once you resolve it to a recipe file, you should be able to look at the
> recipe file's dependencies in dataCache.
> 
> The trouble is you're now resolving all the dependencies in the code I
> think you're referring to. This was in general the job of
> prepare_runqueue() and I'm starting to worry you're duplicating its
> functionality.

Hmm, previously we use the taskdata is to reduce the time for building
up the dependency tree. It seems that we will have to use runqueue to
determine the dependency.

Thanks,
Dongxiao

> 
> Cheers,
> 
> Richard
> 





More information about the yocto mailing list