配方还产生需要包装的 -native 输出 [英] recipe also produces -native output that needs packaging

问题描述

我有一个成功调用遗留构建命令来交叉编译目标的方法.

I have a recipe which successfully invokes a legacy build command to cross-compile a target.

作为一个副作用，它会生成一些在构建中使用的自定义本机工具.

As a side effect it produces some custom native tools that are used in the build.

我想将这些工具收割到一个 -tools-native 包中，以允许其他配方依赖主包来访问工件，并使用 -tools-native 打包以进一步处理这些工件.

I want to reap those tools into a -tools-native package to allow other recipes to depend the main package to access the artifacts, and use the -tools-native package to further process those artifacts.

我可以像添加一样简单地构建这样一个原生包:

I can build such a native package as simply as adding:

PROVIDES = "${PN} ${PN}-tools-native"
SYSROOT_DIRS += "/"
PACKAGES += "${PN}-tools-native"
FILES_${PN}-tools-native += "/native-bin/*"

并让安装部分将本机工具安装到/native-bin/

and having the install section install the native tools to /native-bin/

但不知何故它不是一个真正的本地包，并且当 DEPENDS 被一个额外的配方所依赖时，native-bin 工件被安装在recipe-sysroot<代码>而不是recipe-sysroot-native`

but yet it somehow isn't a real native package, and when DEPENDS'd by an additional recipe the native-bin artifacts are installed inrecipe-sysrootinstead ofrecipe-sysroot-native`

我还必须安装工具 0644 或 bitbake 尝试剥离它们(并且失败，因为它们是本机构建).

I also have to install the tools 0644 or bitbake tries to strip them (and fails, as they are native build).

因为原生工具已经由遗留构建命令生成，所以我不需要作为 -native 配方变体实际调用.

Because the native tools are already generated by the legacy build commands, I don't need to actually invoke as a -native recipe variant.

这是一个漫长的过程，我也不想运行两次.

It's a long process, I don't want to run it twice, either.

目前我通过在 recipe-native-tools 上使用其他配方 DEPEND 并修复权限和路径来解决它

Currently I work around it by having the other recipes DEPEND on recipe-native-tools and fixup the permissions and PATH

但是这样做的正确方法是什么?

But what's the proper way to do this?

推荐答案

这通常由单独的配方处理.没有机制可以共享来自目标配方的本地二进制文件，因为它们的任务哈希包含错误类型的信息(它们根据目标架构而变化).

This is generally handled by separate recipes. There is no mechanism to share native binaries from target recipes as their task hashes have the wrong kinds of information in them (they change depending on the target architecture).

目标配方不会将其 bindir/sbindir 安装到 sysroot 中，因为我们无法运行它们，正如您所提到的，它们是错误的架构，因此它们会混淆 strip 等.

Target recipes don't install their bindir/sbindir into the sysroot since we can't run them and as you mention, they're the wrong architecture so they confuse strip and so on.

您可以尝试使用依赖于该目标配方的本地配方，并将目标配方保存的二进制文件安装到 do_install 处的 ${D} 中.这很可能会发出一些警告，因为通常本地配方不应该依赖于目标配方，但如果您不能构建两次，这可能是您的最佳选择.

You could try having a native recipe which depended upon this target recipe and which installs the binaries saved by the target recipe somewhere into its ${D} at do_install. That may well give some warnings since in general native recipes shouldn't depend on target recipes but is probably your best option if you can't build twice.

这篇关于配方还产生需要包装的 -native 输出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！