(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
========================================================================
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#48306): https://lists.yoctoproject.org/g/yocto/message/48306
Mute This Topic: https://lists.yoctoproject.org/mt/71078290/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
