Re: more pedantry involving the proper use of PREFERRED_PROVIDER_*

["Robert P. J. Day" <rpjday@crashcourse.ca>]

On Thu, 19 Jun 2014, Paul Eggleton wrote:

> On Wednesday 18 June 2014 11:10:47 Robert P. J. Day wrote:
> >   and now, some picky questions about the use and processing of
> > PREFERRED_PROVIDER, once again using actual examples pulled from
> > the poky repository.
> >
> >   first, is there anything magical about the use of the prefix
> > "virtual/" when defining and selecting providers? i'm well aware
> > of the most common usage of this -- "virtual/kernel". and there
> > are other good examples like "virtual/bootloader",
> > "virtual/xserver" and so on.
>
> By and large, no. It is really just a convention. (I say by and
> large because there are a few bits of the code in BitBake and OE
> that do check for this, but they are fairly isolated to the point
> where mentioning them would be confusing.)

  thanks for clearing that up ... i'm not aware of any of the docs
that actually spells that out and i think it's worth mentioning
somewhere.

> >   but there are other non-virtual definitions, such as:
> >
> >   PREFERRED_PROVIDER_console-tools ?= "kbd"
> >
> > so if i select "console-tools" to be incorporated into my eventual
> > image, that line will end up selecting the "kbd" recipe.
>
> So, you have to be careful here; we are selecting a *build-time*
> provider of "console-tools", so we shouldn't muddy the waters by
> starting to talk about packages. The assumption here is that the kbd
> recipe has "console-tools" in its PROVIDES (as does the actual
> console-tools recipe, implicitly). PROVIDES matches up with DEPENDS,
> so if another recipe DEPENDS on "console-tools" then kbd PROVIDES
> that and PREFERRED_PROVIDER ensures it gets selected to do so
> instead of the actual "console-tools" recipe.

  quite so, i could have written that more clearly.

> > so why are some of these preferences using "virtual/" and some
> > not? is it just a philosophical choice? could i do something goofy
> > like define and select names like "rday/recipename" just as well?
>
> Yep.
>
> >   next, wouldn't the preferred provider for a recipe be, by default,
> > that same name? it seems odd to see something like:
> >
> >   PREFERRED_PROVIDER_ltp ?= "ltp"
> >
> > even if something else provides "ltp", isn't the above redundant? or
> > is there something subtle here i'm missing?
>
> We do this kind of thing when one recipe provides the functionality
> of another and thus can stand in its place. I'm not sure if we
> always make an active decision to use one or the other, but I can
> imagine cases where the reverse of the relationship isn't true -
> maybe one can replace the other's functionality but not the other
> way around.

  fair enough, but i don't think that addresses my question -- what's
the value in explicitly setting the PREFERRED_PROVIDER for a recipe to
the same name, which is the default. the ChangeLog file for bitbake
even states, way back for version 1.7.x:

  - Make PREFERRED_PROVIDER_foobar defaults to foobar if available

so while that line above doesn't hurt, it seems pretty clearly
superfluous, and possibly even potentially confusing if a reader
starts to wonder what the point of that line is.

> >   finally, i found this simple example i want to use as a teaching
> > example involving make and remake. there's a definition for the "make"
> > recipe that looks perfectly normal, and there is also a recipe
> > definition for an alternative, remake, whose .bb file contains:
> >
> >   PROVIDES += "make"
> >
> > and whose remake.inc file includes:
> >
> >   ALTERNATIVE_${PN} = "make"
> >   ALTERNATIVE_LINK_NAME[make] = "${bindir}/make"
> >   ALTERNATIVE_TARGET[make] = "${bindir}/remake"
> >   ALTERNATIVE_PRIORITY = "100"
>
> This is alternatives.bbclass in OE, and whilst that it is a
> mechanism for selecting between providers, it is for runtime files
> and doesn't tie in with PREFERRED_PROVIDER at all.

  right, again, i could have worded that more clearly. so, just to be
precise, the line:

  PROVIDES += "make"

defines the "remake" recipe as an alternative to "make" at build time,
while the "ALTERNATIVE" lines are then processed at run-time to set up
the symlinks properly, does that sound right?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================