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
--
_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-devel
