clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[rpjday]

  (currently updating my OE/YP courseware, so the first in a number of
admittedly pedantic questions about simple stuff, just to make
absolutely sure i understand things if i'm going to be explaining it
to others. if appropriate, i can submit patches to the official YP
docs if others think it's worth it and has value.)

  regarding "PROVIDES =" settings in recipe files, first, each recipe
file implicitly PROVIDES its own recipe name, that much is obvious(?).
so in the simplest possible case, the recipe, say, fubar_1.0.0.bb will
always PROVIDE "fubar" and, if that's the case, there is no value in a
PROVIDES line in that recipe file. that is, it would be silly, but
harmless, for that recipe to include the line:

  PROVIDES = "fubar"

  next, given that implicit inclusion, the proper way to provide
another name is with "=", not "+=", yes? i ask this as there are a
number of recipe files under openembedded that do just that:

...
meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb:PROVIDES += "libatomics-ops"
meta/recipes-support/libpcre/libpcre2_10.34.bb:PROVIDES += "pcre2"
meta/recipes-support/libpcre/libpcre_8.43.bb:PROVIDES += "pcre"
meta/recipes-graphics/xorg-xserver/xserver-xorg.inc:PROVIDES += "virtual/xserver"
meta/recipes-graphics/xorg-app/mkfontscale_1.2.1.bb:PROVIDES += "mkfontdir"
... etc etc ...

  i am *assuming* that, in the absence of a compelling reason, the use
of "+=" instead of "=" in this context is harmless, but unnecessary,
correct?

  when would it not be unnecessary? sure, there are cases where a
recipe might require an .inc file which defines a PROVIDES, at which
point the .bb file might append to it. but other than cases like that
(where an earlier PROVIDES actually *needs* to be appended to), is it
safe to say that using "+=" in this context is almost always overkill?

  finally, in order to clarify why someone would want to use PROVIDES,
it seems that falls into a few categories. first, to define an
alternative (generally more generic) name for a recipe, such as:

meta/recipes-support/libpcre/libpcre2_10.34.bb:PROVIDES += "pcre2"
meta/recipes-support/libpcre/libpcre_8.43.bb:PROVIDES += "pcre"
meta/recipes-graphics/xorg-app/mkfontscale_1.2.1.bb:PROVIDES += "mkfontdir"

(i guess that would also include when an older package has been
replaced by a newer equivalent alternative.)

  second reason is to define virtual providers, such as:

meta/recipes-core/glibc/glibc.inc:PROVIDES += "virtual/libintl virtual/libiconv"
meta/recipes-core/newlib/newlib_3.2.0.bb:PROVIDES += "virtual/libc virtual/libiconv virtual/libintl"
meta/recipes-core/musl/musl_git.bb:PROVIDES += "virtual/libc virtual/libiconv virtual/libintl virtual/crypt"

  third reason i can see is in meta-freescale layer, where various
target-dependent u-boot recipes all provide the more generic "u-boot":

recipes-bsp/u-boot/u-boot-imx_2019.04.bb:PROVIDES += "u-boot"
recipes-bsp/u-boot/u-boot-qoriq_2019.04.bb:PROVIDES += "u-boot"
recipes-bsp/u-boot/u-boot-fslc_2019.07.bb:PROVIDES += "u-boot"

  the final occasion is when a recipe defines multiple output
packages, so it might contain the line:

  PROVIDES = "${PACKAGES}"

at that point, the explanation could finish off discussing
PREFERRED_PROVIDER and DEFAULT_PREFERENCE.

  does the above look about right? are there any subtle details of
PROVIDES missing?

rday

-- 

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

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

Re: [yocto] clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[Leon Woestenberg]

Hello Robert,

>   i am *assuming* that, in the absence of a compelling reason, the use
> of "+=" instead of "=" in this context is harmless, but unnecessary,
> correct?
>
My understanding is that:

> meta/recipes-support/libpcre/libpcre_8.43.bb:PROVIDES += "pcre"

means "I provide both "libpcre" as well as "pcre". I am assuming that
PROVIDES = "${PN}" is already set by a core BitBake rule somewhere.
(Didn't check...)

So I think it might be harmful to replace it with "=", as it would no
longer provide libpcre.

Regards,
-- 
Leon Woestenberg

Re: [yocto] clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[rpjday]

On Sat, 8 Feb 2020, Leon Woestenberg wrote:

> Hello Robert,
>
> >   i am *assuming* that, in the absence of a compelling reason, the use
> > of "+=" instead of "=" in this context is harmless, but unnecessary,
> > correct?
> >
> My understanding is that:
>
> > meta/recipes-support/libpcre/libpcre_8.43.bb:PROVIDES += "pcre"
>
> means "I provide both "libpcre" as well as "pcre". I am assuming
> that PROVIDES = "${PN}" is already set by a core BitBake rule
> somewhere. (Didn't check...)
>
> So I think it might be harmful to replace it with "=", as it would
> no longer provide libpcre.

  if that's true, then i've misunderstood it all this time. i guess i
could always RTFS.

rday

Re: [yocto] clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[Jonatan Pålsson]

Hello Robert & Leon,

> So I think it might be harmful to replace it with "=", as it would no
> longer provide libpcre.

I had a look at the variable expansions bitbake -e. Here are two
examples. The vim recipe uses "PROVIDES = xxd" (which would cause
weird effects if = simply overwrote any existing ${PN} value), and the
libpcre2 recipe uses "PROVIDES += pcre2", as already mentioned.

vim:
# $PROVIDES [4 operations]
#   set ... /poky/meta/conf/bitbake.conf:275
#     ""
#   _prepend ... /poky/meta/conf/bitbake.conf:276
#     "${PN} "
#   set ... /poky/meta/conf/documentation.conf:335
#     [doc] "A list of aliases that a recipe also provides. ... SNIP ...
#   set ... /poky/meta/recipes-support/vim/vim_8.2.bb:3
#     "xxd"
# pre-expansion value:
#   "${PN} xxd"
PROVIDES="vim xxd"

libpcre2:
# $PROVIDES [4 operations]
#   set ... /poky/meta/conf/bitbake.conf:275
#     ""
#   _prepend ... /poky/meta/conf/bitbake.conf:276
#     "${PN} "
#   set ... /poky/meta/conf/documentation.conf:335
#     [doc] "A list of aliases that a recipe also provides. ... SNIP ....
#   append ... /poky/meta/recipes-support/libpcre/libpcre2_10.33.bb:24
#     "pcre2"
# pre-expansion value:
#   "${PN}  pcre2"
PROVIDES="libpcre2  pcre2"

My understanding is that ${PN} is always _prepend'ed to PROVIDES, and
due to evaluation order of the different assignment operators,
_prepend will be executed *after* = and +=. This means both
assignments are "harmless". += will give you an extra space though.
See the bottom example here:
https://www.yoctoproject.org/docs/3.1/bitbake-user-manual/bitbake-user-manual.html#variable-interaction-worked-examples

Cheers,
Jonatan

Re: [yocto] clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[rpjday]

On Sat, 8 Feb 2020, Jonatan Palsson wrote:

> Hello Robert & Leon,
>
> > So I think it might be harmful to replace it with "=", as it would no
> > longer provide libpcre.
>
> I had a look at the variable expansions bitbake -e. Here are two
> examples. The vim recipe uses "PROVIDES = xxd" (which would cause
> weird effects if = simply overwrote any existing ${PN} value), and the
> libpcre2 recipe uses "PROVIDES += pcre2", as already mentioned.
>
> vim:
> # $PROVIDES [4 operations]
> #   set ... /poky/meta/conf/bitbake.conf:275
> #     ""
> #   _prepend ... /poky/meta/conf/bitbake.conf:276
> #     "${PN} "
> #   set ... /poky/meta/conf/documentation.conf:335
> #     [doc] "A list of aliases that a recipe also provides. ... SNIP ...
> #   set ... /poky/meta/recipes-support/vim/vim_8.2.bb:3
> #     "xxd"
> # pre-expansion value:
> #   "${PN} xxd"
> PROVIDES="vim xxd"
>
> libpcre2:
> # $PROVIDES [4 operations]
> #   set ... /poky/meta/conf/bitbake.conf:275
> #     ""
> #   _prepend ... /poky/meta/conf/bitbake.conf:276
> #     "${PN} "
> #   set ... /poky/meta/conf/documentation.conf:335
> #     [doc] "A list of aliases that a recipe also provides. ... SNIP ....
> #   append ... /poky/meta/recipes-support/libpcre/libpcre2_10.33.bb:24
> #     "pcre2"
> # pre-expansion value:
> #   "${PN}  pcre2"
> PROVIDES="libpcre2  pcre2"

  argh ... that is, of course, what i should have done first, just
check the environment for the recipe. ok, that pretty much confirms
that, barring some exceptional circumstances, most instances of
"PROVIDES +=" are not harmful, just redundant.

rday

Re: [yocto] clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[rpjday]

On Sat, 8 Feb 2020, Jonatan Palsson wrote:

.... snip ...

> See the bottom example here:
> https://www.yoctoproject.org/docs/3.1/bitbake-user-manual/bitbake-user-manual.html#variable-interaction-worked-examples

  ironically, i am shortly going to ask a convoluted question about
this very thing -- overrides and appends. stick around. :-)

rday

Re: [yocto] clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[rpjday]

On Sat, 8 Feb 2020, Jonatan Palsson wrote:

> Hello Robert & Leon,
>
> > So I think it might be harmful to replace it with "=", as it would no
> > longer provide libpcre.
>
> I had a look at the variable expansions bitbake -e. Here are two
> examples. The vim recipe uses "PROVIDES = xxd" (which would cause
> weird effects if = simply overwrote any existing ${PN} value), and the
> libpcre2 recipe uses "PROVIDES += pcre2", as already mentioned.
>
> vim:
> # $PROVIDES [4 operations]
> #   set ... /poky/meta/conf/bitbake.conf:275
> #     ""
> #   _prepend ... /poky/meta/conf/bitbake.conf:276
> #     "${PN} "
> #   set ... /poky/meta/conf/documentation.conf:335
> #     [doc] "A list of aliases that a recipe also provides. ... SNIP ...
> #   set ... /poky/meta/recipes-support/vim/vim_8.2.bb:3
> #     "xxd"
> # pre-expansion value:
> #   "${PN} xxd"
> PROVIDES="vim xxd"
>
> libpcre2:
> # $PROVIDES [4 operations]
> #   set ... /poky/meta/conf/bitbake.conf:275
> #     ""
> #   _prepend ... /poky/meta/conf/bitbake.conf:276
> #     "${PN} "
> #   set ... /poky/meta/conf/documentation.conf:335
> #     [doc] "A list of aliases that a recipe also provides. ... SNIP ....
> #   append ... /poky/meta/recipes-support/libpcre/libpcre2_10.33.bb:24
> #     "pcre2"
> # pre-expansion value:
> #   "${PN}  pcre2"
> PROVIDES="libpcre2  pcre2"
>
> My understanding is that ${PN} is always _prepend'ed to PROVIDES, and
> due to evaluation order of the different assignment operators,
> _prepend will be executed *after* = and +=. This means both
> assignments are "harmless". += will give you an extra space though.

  to summarize (and one last question), first, it would be utterly
superfluous for any recipe to "PROVIDES" its own exact name. i'm not
saying i've seen that in any of the OE/YP recipes, but i have taught
courses where students who have been using OE/YP have been under the
mistaken impression that they needed to do that, and were adding a
"PROVIDES = " line to every recipe file they wrote.

  second, i think we all agree that it is rarely necessary to use
"PROVIDES +=", although i did run across one case in
recipes-core/glibc/glibc.inc:

  PROVIDES = "virtual/libc"
  PROVIDES += "virtual/libintl virtual/libiconv"

where, sure, if you break it over more than one line, yes, then you
need it.

  and a final question ... i just noticed the line:

  PROVIDES = ""

in a couple files:

$ grep -r "^PROVIDES = \"\"" *
meta/conf/bitbake.conf:PROVIDES = ""
meta/recipes-core/glibc/glibc-testsuite_2.31.bb:PROVIDES = ""
meta/recipes-core/libxcrypt/libxcrypt-compat_4.4.10.bb:PROVIDES = ""
$

  in that first file is the snippet:

  # strip provides
  PROVIDES = ""

i had never noticed that being done before, and the comment suggests
that this is somehow resetting or clearing the PROVIDES value. is that
what this is doing? am i misreading this?

  thanks to all for assisting in my courseware cleanup. slowly but
surely...

rday

Re: [yocto] clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[Richard Purdie]

On Tue, 2020-02-11 at 05:32 -0500, rpjday@crashcourse.ca wrote:
>   second, i think we all agree that it is rarely necessary to use
> "PROVIDES +=", although i did run across one case in
> recipes-core/glibc/glibc.inc:
> 
>   PROVIDES = "virtual/libc"
>   PROVIDES += "virtual/libintl virtual/libiconv"
> 
> where, sure, if you break it over more than one line, yes, then you
> need it.

I think the original intent was that bitbake.conf defines the basic
PROVIDES/DEPENDS and then the recipes adjust as needed.

As such, PROVIDES and DEPENDS would then always use +=.

Unfortunately over the years this has gotten lost and bitbake.conf and
base.bbclass had to become more inventive about how they set the
defaults for the variables.

As such, I think += actually makes sense but I realise that isn't the
way most recipes work now. We could try and fix that but it does seem
like a marginal gain when there are bigger issues.

Cheers,

Richard

Re: [yocto] clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[rpjday]

On Tue, 11 Feb 2020, Richard Purdie wrote:

> On Tue, 2020-02-11 at 05:32 -0500, rpjday@crashcourse.ca wrote:
> >   second, i think we all agree that it is rarely necessary to use
> > "PROVIDES +=", although i did run across one case in
> > recipes-core/glibc/glibc.inc:
> >
> >   PROVIDES = "virtual/libc"
> >   PROVIDES += "virtual/libintl virtual/libiconv"
> >
> > where, sure, if you break it over more than one line, yes, then you
> > need it.
>
> I think the original intent was that bitbake.conf defines the basic
> PROVIDES/DEPENDS and then the recipes adjust as needed.
>
> As such, PROVIDES and DEPENDS would then always use +=.
>
> Unfortunately over the years this has gotten lost and bitbake.conf
> and base.bbclass had to become more inventive about how they set the
> defaults for the variables.
>
> As such, I think += actually makes sense but I realise that isn't
> the way most recipes work now. We could try and fix that but it does
> seem like a marginal gain when there are bigger issues.

  oh, i wasn't suggesting any sort of massive cleanup; i just wanted
to make sure i was explaining it properly to any potential students to
make sure they appreciated corner cases like this.

rday