Date
1 - 9 of 9
clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)
|
Robert P. J. Day
(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 ========================================================================
|
|
|
|
Leon Woestenberg
Hello Robert,
i am *assuming* that, in the absence of a compelling reason, the useMy 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
|
|
|
|
Robert P. J. Day
On Sat, 8 Feb 2020, Leon Woestenberg wrote:
Hello Robert,if that's true, then i've misunderstood it all this time. i guess ii am *assuming* that, in the absence of a compelling reason, the useMy understanding is that: could always RTFS. rday
|
|
|
|
Jonatan Pålsson
Hello Robert & Leon,
So I think it might be harmful to replace it with "=", as it would noI 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
|
|
|
|
Robert P. J. Day
On Sat, 8 Feb 2020, Jonatan Palsson wrote:
Hello Robert & Leon,argh ... that is, of course, what i should have done first, justSo I think it might be harmful to replace it with "=", as it would noI had a look at the variable expansions bitbake -e. Here are two 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
|
|
|
|
Robert P. J. Day
On Sat, 8 Feb 2020, Jonatan Palsson wrote:
.... snip ... See the bottom example here:ironically, i am shortly going to ask a convoluted question about this very thing -- overrides and appends. stick around. :-) rday
|
|
|
|
Robert P. J. Day
On Sat, 8 Feb 2020, Jonatan Palsson wrote:
Hello Robert & Leon,to summarize (and one last question), first, it would be utterlySo I think it might be harmful to replace it with "=", as it would noI had a look at the variable expansions bitbake -e. Here are two 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
|
|
|
|
Richard Purdie
On Tue, 2020-02-11 at 05:32 -0500, rpjday@... wrote:
second, i think we all agree that it is rarely necessary to useI 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
|
|
|
|
Robert P. J. Day
On Tue, 11 Feb 2020, Richard Purdie wrote:
On Tue, 2020-02-11 at 05:32 -0500, rpjday@... wrote:oh, i wasn't suggesting any sort of massive cleanup; i just wantedsecond, i think we all agree that it is rarely necessary to useI think the original intent was that bitbake.conf defines the basic to make sure i was explaining it properly to any potential students to make sure they appreciated corner cases like this. rday
|
|
|