【发布时间】:2015-08-30 18:52:09
【问题描述】:
情况是:有一个ipk叫A,另一个叫B。
B 对 A 有运行时依赖项(根据 A 的 bitbake 配方)
但是,B 中的源文件有 #include <some_header_in_A>
这对我来说似乎是一个构建依赖项,但我无法向自己解释为什么 bitbake 配方具有运行时依赖项。
任何帮助表示赞赏,还有一些解释性教程的链接。
【问题讨论】:
标签: c++ dependencies bitbake
情况是:有一个ipk叫A,另一个叫B。
B 对 A 有运行时依赖项(根据 A 的 bitbake 配方)
但是,B 中的源文件有 #include <some_header_in_A>
这对我来说似乎是一个构建依赖项,但我无法向自己解释为什么 bitbake 配方具有运行时依赖项。
任何帮助表示赞赏,还有一些解释性教程的链接。
【问题讨论】:
标签: c++ dependencies bitbake
回想一下我的answer to your other question。
如果 T 依赖于 P 则 T 的 do_configure 任务将依赖于
P 的 do_populate_sysroot 任务。
如果 T RDEPENDS 在 P 上,则 T 的 do_build 任务将依赖于 P的
do_package_write 任务。
所以你的 B RDEPENDS 在你的 A 上意味着 A 已经
在构建B 时通过do_package_write 的所有阶段,包括
do_populate_sysroot。因此,A 导出到 sysroot 的任何标头
当 B 被构建时就已经存在了,并且构建时依赖将被满足。
如果 B 包含由 A 导出的标头,则此 is 是构建时依赖项。但是那个 不排除 B 也对 A 有运行时依赖。其实通常是 如果 B 是运行时依赖于 A 那么它也是构建时依赖的情况 在 A 上,正是因为(对于 C/C++ 包)运行时依赖项通常 意味着构建 B 需要来自 A 的标头。
如果你的食谱只在A上指定BRDEPENDS,那么它需要一点点
运气成功。如果碰巧是B的do_configure
包括检查 A 标头是否存在,和
B 的do_configure
在 A 的 do_populate_sysroot 完成之前运行,那么
检查 A 标头可能会失败。
为了使配方完全正确和安全,它应该同时指定
B RDEPENDS 在 A 和 B DEPENDS 在 A .
【讨论】: