[oe] bitbake dependency question

[Paul Eggleton]

Hi Robert,

On Tue, 13 Dec 2016 04:47:31 Robert Cagle wrote:
> Robert Yang wrote:
> > Try something like:
> > In recipeD.bb:
> > PLUGIN_RECIPES ??= "A" (or b, c)
> > DEPENDS = "${PLUGIN_RECIPES} other..."
> > 
> > In local.conf:
> > PLUGIN_RECIPES = "A" (or b, c).
> 
> Hi Robert,
> Thanks for the response! My current solution is similar to what you suggest:
> 
> local.conf
> PLUGIN_RECIPES = "recipeA recipeB recipeC"
> 
> recipeD.bb:
> DEPENDS = "${PLUGIN_RECIPES} other"
> 
> I'm assuming the weak reference in 'PLUGIN_RECIPES ??= "A" (or b, c)'  is to
> prevent errors if someone forgets to define PLUGIN_RECIPES in local.conf?

Correct, ??= is a "weak" or "lazy" default.
 
> I was hoping to do something like this in an image recipe:
> my-image.bb:
>    IMAGE_INSTALL_append = " recipeA  recipeB recipeC recipeD"
> and have the rest happen automatically based on the contents of those
> recipes.
> 
> However, maybe I could at least do:
> my-image.bb:
>    IMAGE_INSTALL_append = " ${PLUGIN_RECIPES} recipeD  other..."

This will almost certainly be fine in your case, but something to bear in mind 
is that IMAGE_INSTALL refers to packages, not recipes. By default the main 
package of a recipe is the same name as the recipe, but it doesn't have to be 
that way.

> and have everything controlled from local.conf by one variable. I'd rather
> have it the other way around (defined once in my-image.bb), but I can live
> with this. Thanks again!

FYI, one of the basic principles of the way OE works is that one recipe cannot 
affect the processing of another except by way of the sysroot (and then the 
first recipe must also be in the second's DEPENDS) - many other parts of the 
system rest upon this design. Hence why you can't say "in this image I want 
this other recipe built in this way, and in that image I want it built in that 
other way". All you get to control in an image recipe is which packages to 
include, and maybe do some post-processing. Of course, you can set variables 
at the configuration level and have multiple recipes pick it up, as in the 
above example.

Another way to handle this kind of situation with plugins is to simply build 
them all with all dependencies, and have the runtime design such that it's 
fully flexible as to which plugins are installed - then you just make the 
choice in the image. (Perhaps what you're building is already that way and 
you're just trying to save on build time?)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre