如何为 Yocto 配方构建 do_install,以确保将 debian 软件包从部署 debs 文件夹复制到 ${D}

发布于 01-13 15:51 字数 7045 浏览 3 评论 0原文

我有一个简单的 Yocto 配方,它使用 ssh 从服务器上的存储库获取代码,调用构建名为“libcustom.a”的库的 makefile,将库复制到工作目录 ${B}/git 中的 /usr/lib,最后尝试将 debian 软件包添加到目标目录 ${D} 之前。最后一步是我遇到问题的地方。

配方-lib 调用以下任务 - 'do_install' 中的第 37 行引用:

SUMMARY = "bitbake-layers recipe"
DESCRIPTION = "Creating a debian package for a custom library"
PRIORITY = "optional"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

SRC_URI = "git://<server>:/opt/Eagle-Proj/Custom_lib;protocol=ssh;branch=master"
SRCREV = "c5aa799664abc189639e07cd284a0adcf4c282ed"

S = "${WORKDIR}/git"

FILES_${PN} = "custom-lib-*.deb"
FILES_${PN} = "${B}${bindir}/*"
FILES_${PN} = "${B}${libdir}/*"
#FILES_${PN} = "${D}${bindir}/*"
#FILES_${PN} = "${D}${libdir}/*"

do_compile() {
    make CC="${CC}" AR="${AR}" lib
}

do_install() {
    install -d ${B}${libdir}
    install -m 0644 ${S}/build/arm/lib/libcustom.a ${B}${libdir}
    #install -D ${WORKDIR}/deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-*.deb ${D}
    #note: commented out line above is line #37
}

我的层结构如下:

在此处输入图像描述

'fetch' 和后续 make 不是问题,因此 SRC_URI 和 SRCREV 配置正确。请注意,我更改了一些路径/文件名,以避免泄露公司/产品信息。因此-lib 本质上是配方/包名称。 清理后,如果我通过 排除 第 37 行使用 bitbake 构建配方,将其称为序列 #2,通常会调用以下任务。

do_deploy_source_date_epoch_setscene (90181): log.do_deploy_source_date_epoch_setscene.90181
do_populate_lic_setscene (90180): log.do_populate_lic_setscene.90180
do_fetch (90197): log.do_fetch.90197
do_unpack (90201): log.do_unpack.90201
do_prepare_recipe_sysroot (90202): log.do_prepare_recipe_sysroot.90202
do_patch (90222): log.do_patch.90222
do_configure (90230): log.do_configure.90230
do_compile (90234): log.do_compile.90234
do_install (90309): log.do_install.90309
do_package (90319): log.do_package.90319
do_populate_sysroot (90320): log.do_populate_sysroot.90320
do_packagedata (90401): log.do_packagedata.90401
do_package_write_deb (90489): log.do_package_write_deb.90489
do_package_qa (90490): log.do_package_qa.90490

生成的自定义库位于以下文件夹中:/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/-lib/0.1-r0/git/build/arm/lib/libcustom.a

复制自定义库到 /usr/lib/ 文件夹,如下所示:/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/-lib/0.1-r0/git/usr/lib/libcustom.a

debian 软件包已在以下位置创建工作目录 ${B} 下的 deploy_debs 文件夹,即/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/-lib/0.1-r0/deploy-debs/cortexa7t2hf-neon-vfpv4/ 按预期填充:

<my_custom>-lib-dbg_0.1-r0.233_armhf.deb
<my_custom>-lib-dev_0.1-r0.233_armhf.deb

到目前为止,一切都很好。

现在,第 #37 行的预期目的是确保 debian 软件包最终位于以下文件夹中:

./image/<my_custom>-lib-dbg_0.1-r0.81_armhf.deb
./image/<my_custom>-lib-dev_0.1-r0.81_armhf.deb
./package/<my_custom>-lib-dbg_0.1-r0.81_armhf.deb
./package/<my_custom>-lib-dev_0.1-r0.81_armhf.deb
./deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-dbg_0.1-r0.82_armhf.deb
./deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-dev_0.1-r0.82_armhf.deb
./packages-split/<my_custom>-lib/<my_custom>-lib-dbg_0.1-r0.81_armhf.deb
./packages-split/<my_custom>-lib/<my_custom>-lib-dev_0.1-r0.81_armhf.deb

如果最初我在清理后构建配方,则使用第 #37 行包含,调用的任务序列,将其称为序列 #1,如下所示:

do_deploy_source_date_epoch_setscene (91243): log.do_deploy_source_date_epoch_setscene.91243
do_populate_lic_setscene (91242): log.do_populate_lic_setscene.91242
do_fetch (91259): log.do_fetch.91259
do_unpack (91263): log.do_unpack.91263
do_prepare_recipe_sysroot (91264): log.do_prepare_recipe_sysroot.91264
do_patch (91285): log.do_patch.91285
do_configure (91292): log.do_configure.91292
do_compile (91296): log.do_compile.91296
do_install (91373): log.do_install.91373

序列 #1 在“do_install”上失败,并且出现以下错误:

DEBUG: Executing shell function do_install
| install: cannot stat '<my_workspace>/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux- 
gnueabi/<my_custom>-lib/0.1-r0/deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-*.deb': No 
such file or directory

对于序列 #1,因为命令行 #37 正在尝试复制来自deploy-debs文件夹的-lib-*.deb,出现错误似乎是因为Yocto足够聪明来检查“deploy-debs”文件夹和文件是否存在,但是这个过程还为时过早,为了我想要实现的目标。正如我们在序列 #2 中看到的,其中一个任务首先将 debian 文件写入“deploy-debs”文件夹,这在序列 #1 中不会发生。直观上,人们会假设实现这一目标的任务是 'do_package_write_deb' 。

假设我跑了两次。我首先构建配方,排除第37行(序列#2),然后编辑配方并重新包含第37行(序列#3)并重新调用构建没有在两个序列之间进行清理。我不太明白执行序列 #3 后 debian 文件如何最终出现在包、图像和包分割文件夹中,但是文件存在

因此,对于不同运行,序列 #2 执行以下操作:

do_deploy_source_date_epoch_setscene (101280): log.do_deploy_source_date_epoch_setscene.101280
do_fetch (101296): log.do_fetch.101296
do_unpack (101300): log.do_unpack.101300
do_prepare_recipe_sysroot (101301): log.do_prepare_recipe_sysroot.101301
do_patch (101325): log.do_patch.101325
do_configure (101329): log.do_configure.101329
do_compile (101333): log.do_compile.101333
do_install (101405): log.do_install.101405
do_populate_sysroot (101416): log.do_populate_sysroot.101416
do_package (101415): log.do_package.101415
do_packagedata (101497): log.do_packagedata.101497
do_package_write_deb (101585): log.do_package_write_deb.101585
do_package_qa (101586): log.do_package_qa.101586

在运行序列 #2 后创建了“deploy-debs”文件夹,序列 #3 将以下附加任务添加到“ log.task_order' 文件:

do_compile (102023): log.do_compile.102023
do_install (102036): log.do_install.102036
do_populate_sysroot (102048): log.do_populate_sysroot.102048
do_package (102047): log.do_package.102047
do_packagedata (102129): log.do_packagedata.102129
do_package_write_deb (102217): log.do_package_write_deb.102217
do_package_qa (102218): log.do_package_qa.102218 

我在 log.do_package_write_deb.102217 中注意到以下内容:

DEBUG: Preparing tree <my_workspace>/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux- 
gnueabi/<my_custom>-lib/0.1-r0/**deploy-debs** for packaging at <my_workspace>/tmp- 
glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/<my_custom>-lib/0.1-r0/sstate-build- 
package_write_deb/deploy-debs

我尝试通过创建自己的任务进行实验,看看是否可以影响执行的顺序,但没有成功。

 do_after_install() {
     install -D ${WORKDIR}/deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-*.deb ${D}
 }
 
 addtask after_install after do_install before do_package

事实上,必须有一种更简单的方法来获得正确的结果,而不必诉诸上述方法。我怀疑#37不正确,需要更换。如何创建 debian 软件包?我在谷歌上进行了广泛的搜索,但找不到与我想做的事情相关的任何有用的例子。

我是 Yocto 的新手,所以我希望能得到这方面的帮助。提前非常感谢,并对如此多的细节表示歉意,但我认为这都是相关的。

I have a simple Yocto recipe that fetches code from repositories on a server using ssh, invokes a makefile that builds a library called 'libcustom.a', copies the library to /usr/lib in the working directory ${B}/git, before finally attempting to add the debian packages to the destination directory ${D}. The last step is where I have an issue.

The recipe <my_custom>-lib invokes the following tasks - line #37 in 'do_install' refers:

SUMMARY = "bitbake-layers recipe"
DESCRIPTION = "Creating a debian package for a custom library"
PRIORITY = "optional"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

SRC_URI = "git://<server>:/opt/Eagle-Proj/Custom_lib;protocol=ssh;branch=master"
SRCREV = "c5aa799664abc189639e07cd284a0adcf4c282ed"

S = "${WORKDIR}/git"

FILES_${PN} = "custom-lib-*.deb"
FILES_${PN} = "${B}${bindir}/*"
FILES_${PN} = "${B}${libdir}/*"
#FILES_${PN} = "${D}${bindir}/*"
#FILES_${PN} = "${D}${libdir}/*"

do_compile() {
    make CC="${CC}" AR="${AR}" lib
}

do_install() {
    install -d ${B}${libdir}
    install -m 0644 ${S}/build/arm/lib/libcustom.a ${B}${libdir}
    #install -D ${WORKDIR}/deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-*.deb ${D}
    #note: commented out line above is line #37
}

My layers structure is as follows:

enter image description here

The 'fetch' and subsequent make are not the issue, so SRC_URI and SRCREV configured correctly. Please note that I have changed some paths/file names to avoid disclosing company/product info. Thus <my_custom>-lib is essentially the recipe/package name.
After a clean, if I build the recipe using bitbake by excluding line #37, calling it sequence #2, the following tasks are invoked, typically.

do_deploy_source_date_epoch_setscene (90181): log.do_deploy_source_date_epoch_setscene.90181
do_populate_lic_setscene (90180): log.do_populate_lic_setscene.90180
do_fetch (90197): log.do_fetch.90197
do_unpack (90201): log.do_unpack.90201
do_prepare_recipe_sysroot (90202): log.do_prepare_recipe_sysroot.90202
do_patch (90222): log.do_patch.90222
do_configure (90230): log.do_configure.90230
do_compile (90234): log.do_compile.90234
do_install (90309): log.do_install.90309
do_package (90319): log.do_package.90319
do_populate_sysroot (90320): log.do_populate_sysroot.90320
do_packagedata (90401): log.do_packagedata.90401
do_package_write_deb (90489): log.do_package_write_deb.90489
do_package_qa (90490): log.do_package_qa.90490

The generated custom library is located in the following folder:
<my_workspace>/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/<my_custom>-lib/0.1-r0/git/build/arm/lib/libcustom.a

The custom library is copied to the /usr/lib/ folder as follows:
<my_workspace>/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/<my_custom>-lib/0.1-r0/git/usr/lib/libcustom.a

The debian packages have been created in the deploy_debs folder off the working directory ${B} i.e.
<my_workspace>/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/<my_custom>-lib/0.1-r0/deploy-debs/cortexa7t2hf-neon-vfpv4/, is populated as expected:

<my_custom>-lib-dbg_0.1-r0.233_armhf.deb
<my_custom>-lib-dev_0.1-r0.233_armhf.deb

So far so good.

Now, the intended purpose of line #37 is to ensure that debian packages end up in the following folders:

./image/<my_custom>-lib-dbg_0.1-r0.81_armhf.deb
./image/<my_custom>-lib-dev_0.1-r0.81_armhf.deb
./package/<my_custom>-lib-dbg_0.1-r0.81_armhf.deb
./package/<my_custom>-lib-dev_0.1-r0.81_armhf.deb
./deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-dbg_0.1-r0.82_armhf.deb
./deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-dev_0.1-r0.82_armhf.deb
./packages-split/<my_custom>-lib/<my_custom>-lib-dbg_0.1-r0.81_armhf.deb
./packages-split/<my_custom>-lib/<my_custom>-lib-dev_0.1-r0.81_armhf.deb

If initially I build the recipe after a clean, with line #37 included, the sequence of tasks invoked, call it sequence #1, is as follows:

do_deploy_source_date_epoch_setscene (91243): log.do_deploy_source_date_epoch_setscene.91243
do_populate_lic_setscene (91242): log.do_populate_lic_setscene.91242
do_fetch (91259): log.do_fetch.91259
do_unpack (91263): log.do_unpack.91263
do_prepare_recipe_sysroot (91264): log.do_prepare_recipe_sysroot.91264
do_patch (91285): log.do_patch.91285
do_configure (91292): log.do_configure.91292
do_compile (91296): log.do_compile.91296
do_install (91373): log.do_install.91373

Sequence #1 fails on the 'do_install' and I get the following error:

DEBUG: Executing shell function do_install
| install: cannot stat '<my_workspace>/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux- 
gnueabi/<my_custom>-lib/0.1-r0/deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-*.deb': No 
such file or directory

For sequence #1, because the command line #37 is attempting a copy of <my_custom>-lib-*.deb from the deploy-debs folder, the error appears to occur because Yocto is clever enough to check for the existence of the 'deploy-debs' folder and files however it is too early in the process, for what I'm trying to achieve. As we've seen in sequence #2, one of the tasks writes the debian files to the 'deploy-debs' folder in the first place, which doesn't occur in sequence #1. Intuitively, one would assume the task that achieves this to be 'do_package_write_deb' .

Assume I do two runs. I first build the recipe with line #37 excluded (sequence #2), before editing the recipe and re-including line #37 (sequence #3) and re-invoking the build without doing a clean between the two sequences. I don't quite understand how the debian files end up in the package, image and package-split folders after executing sequence #3 however the files are present.

For a different run, therefore, sequence #2 executes the following:

do_deploy_source_date_epoch_setscene (101280): log.do_deploy_source_date_epoch_setscene.101280
do_fetch (101296): log.do_fetch.101296
do_unpack (101300): log.do_unpack.101300
do_prepare_recipe_sysroot (101301): log.do_prepare_recipe_sysroot.101301
do_patch (101325): log.do_patch.101325
do_configure (101329): log.do_configure.101329
do_compile (101333): log.do_compile.101333
do_install (101405): log.do_install.101405
do_populate_sysroot (101416): log.do_populate_sysroot.101416
do_package (101415): log.do_package.101415
do_packagedata (101497): log.do_packagedata.101497
do_package_write_deb (101585): log.do_package_write_deb.101585
do_package_qa (101586): log.do_package_qa.101586

With the 'deploy-debs' folder having been created after sequence #2 is run, sequence #3 adds the following additional tasks to the 'log.task_order' file:

do_compile (102023): log.do_compile.102023
do_install (102036): log.do_install.102036
do_populate_sysroot (102048): log.do_populate_sysroot.102048
do_package (102047): log.do_package.102047
do_packagedata (102129): log.do_packagedata.102129
do_package_write_deb (102217): log.do_package_write_deb.102217
do_package_qa (102218): log.do_package_qa.102218 

I noticed the following in log.do_package_write_deb.102217:

DEBUG: Preparing tree <my_workspace>/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux- 
gnueabi/<my_custom>-lib/0.1-r0/**deploy-debs** for packaging at <my_workspace>/tmp- 
glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/<my_custom>-lib/0.1-r0/sstate-build- 
package_write_deb/deploy-debs

I have tried experimenting by creating my own tasks to see if I could influence the sequence executed but without success.

 do_after_install() {
     install -D ${WORKDIR}/deploy-debs/cortexa7t2hf-neon-vfpv4/<my_custom>-lib-*.deb ${D}
 }
 
 addtask after_install after do_install before do_package

In actual fact, there must be a simpler way to achieve the correct result without having to resort to the above. I suspect that #37 is not correct and needs to be replaced. How do I create the debian packages? I have googled extensively but can't find any useful examples that relate to what I'm trying to do.

I am a relative novice at Yocto, so I would appreciate help on this. Many thanks in advance and apologies for there being so much detail however I think it's all relevant.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文