【问题标题】:Optional dependency in a bitbake recipebitbake 配方中的可选依赖项
【发布时间】:2021-07-08 22:56:55
【问题描述】:

假设我有一个包foo,它会自动检测另一个包bar,并在bar 存在时启用额外的功能。但是,foo 可以在没有bar 的情况下构建并正常工作。如何在foo 的配方中表示这种依赖关系?我想到的事情:

  • 我可以将bar 添加到fooDEPENDS,但这意味着现在只要图像包含foo,就会始终安装bar
  • 我什么都做不了,但是 foo 会随机包含额外的功能,这取决于 bar 是在之前还是之后编译的。
  • 我可以添加一个PACKAGECONFIG[bar] = ",,bar",但是当我将它添加到图像时,我必须记住将bar 添加到fooPACKAGECONFIG,并在我想从图像中删除它时删除它.

有没有办法告诉 bitbake foo 在没有 bar 的情况下可以正常构建,但如果两者都存在,那么应该先构建 bar


为了让事情更清楚,假设我在fooconfigure.ac 中有以下内容:

PKG_CHECK_MODULES([BAR], [bar], [AC_DEFINE([HAVE_BAR]), [1], [Is bar available?])])

然后在foo.c:

#ifdef HAVE_BAR
#include <bar.h>
#endif

/* And later: */
void foo_init (void)
{
#if HAVE_BAR
   bar_init();
   enable_bar_functionnality();
#endif
}

所以foo 将在编译时检测bar 是否存在并激活或不激活相应的功能

【问题讨论】:

  • 编译时 foo 是否依赖于 bar 中的某些内容?
  • 是的,bar 提供了一个库,如果它可用,则 foo 启用调用此库的功能 → 在编译时需要库和标头。
  • 你能在你的食谱中告诉我foo如何检测bar是否可用吗?
  • 检测不是在配方中完成的,它是由configure脚本完成的(例如PKG_CHECK_MODULESAC_CHECK_LIB)。
  • 您使用的是最新版本的 yocto 吗?您的注释“foo 是否会随机包含额外功能,具体取决于 bar 是在之前还是之后编译的”,这在 yocto 构建到通用 sysroot 时一直发生,但现在每个包都有自己的 sysroot。这大大减少了构建薄片。 (也大大增加了磁盘的使用量……)

标签: yocto bitbake


【解决方案1】:

如果我正确理解了您的问题,那么您有 foo 在运行时检测到 bar 的存在。一种更类似于 yocto-ish 的方法是在编译时明确功能和依赖关系,以便在构建映像时包含所需的内容。

您可以通过使用 PACKAGECONFIG 定义 foo 的“功能”或使用 PACKAGES 定义多个包来做到这一点。前者允许您设置编译器参数;后者仅允许您定义要部署的文件子集。无论哪种方式,您都可以定义仅适用于 foo+bar 情况的RDEPENDS(“运行时依赖”)。

使用PACKAGES

DEPENDS 是编译时依赖项,即编译或组装配方中定义的所有包所需的东西。这些文件只有在被定义为带有 FILES 的包的一部分时才会出现在映像中。

DEPENDS += "bar"
PACKAGES += "foo foo-with-bar"
FILES_foo = "${bindir}/foo"
FILES_foo-with-bar = "${bindir}/foo ${bindir}/bar"
# probably not necessary since bar is included in foo-with-bar
# and RDEPENDS should be set to this automatically
# RDEPENDS_foo-with-bar += "bar"

使用PACKAGECONFIG

我发现PACKAGECONFIG 很难使用,但是如果你需要在bar 支持中编译,这是要走的路。它最多需要六个参数,包括runtime-deps-for-f1,这是您在启用foo 的条形功能时安装bar 所需要的。

PACKAGECONFIG[f1] = "\
    --with-f1, \
    --without-f1, \
    build-deps-for-f1, \
    runtime-deps-for-f1, \
    runtime-recommends-for-f1, \
    packageconfig-conflicts-for-f1"

poky/meta 中设置运行时依赖的一个配方是 recipes-connectivity/connman/connman.inc

PACKAGECONFIG[nftables] = " \
  --with-firewall=nftables , \
  , \
  libmnl libnftnl,\
  , \
  kernel-module-nf-tables kernel-module-nft-chain-nat-ipv4 (...) \
"

【讨论】:

  • PACKAGES 将不起作用,因为无论bar 是否存在(尽管内容不同),foo 都会生成相同的文件。我已经展示了 PACKAGECONFIG 如何用于我的用例以及为什么它不令人满意。
  • 我同意PACKAGES 不起作用,但PACKAGECONFIG 应该。如果 PACKAGECONFIG[bar] 功能将包bar 识别为构建dep 和运行时dep,那么bar 将在foo 之前构建(作为构建dep)并放入foo 的假sysroot。当 foo 被编译时,它应该在假的 sysroot 中看到 bar,并执行 foo 在看到 bar 时所做的任何事情。构建映像后, bar 将作为运行时 dep 被拾取。如果功能栏被禁用,这些事情都不会发生,你会得到没有栏的 foo。无论哪种方式,您都不应该在图像定义中乱用 bar。
  • 我没有说PACKAGECONFIG 不起作用。事实上,我确实明确表示它确实有效,但并不令人满意。 PACKAGECONFIG 的问题是,现在我必须为所有可能依赖于 bar 的软件包启用 bar 选项,这违反了 DRY 原则。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-11-15
  • 1970-01-01
  • 2015-08-28
  • 2021-09-17
  • 1970-01-01
  • 2011-09-08
  • 2016-03-12
相关资源
最近更新 更多