BuildRoot - Understanding how to rebuild packages(try know why)

最新推荐文章于 2024-04-17 17:30:17 发布

swingboard

最新推荐文章于 2024-04-17 17:30:17 发布

阅读量1.2k

点赞数

分类专栏： Linux学习

本文链接：https://blog.csdn.net/swingboard/article/details/19995327

版权

Linux学习专栏收录该内容

8 篇文章 0 订阅

订阅专栏

本文深入探讨了在BuildRoot系统中如何重建包，通过解析内部使用到的stamp文件来追踪已完成与待完成的步骤，以及如何通过删除特定文件触发包的重新编译过程。重点解释了stamp_configured文件的作用，当该文件被移除时，如何导致从配置步骤开始的重新编译。同时，阐述了Make工作原理中关于依赖关系和重新构建的机制，为开发者提供了解决重建包问题的关键思路。

摘要由CSDN通过智能技术生成

In BuildRoot document 3.5.2 Understanding how to rebuild packages, there are statements:

Internally, to keep track of which steps have been done andwhich steps remain to be done, Buildroot maintains stamp files (emptyfiles that just tell whether this or that action has been done):

output/build/<package>-<version>/.stamp_configured. If removed, Buildroot will trigger the recompilation of the package from the configuration step (execution of./configure).
output/build/<package>-<version>/.stamp_built. If removed, Buildroot will trigger the recompilation of the package from the compilation step (execution ofmake).

I want figure out why rm output/build/<package>-<version>/.stamp_configured, the package will recompile from the configuration step.

Look at build/package/pkg-generic.c

$(BUILD_DIR)/%/.stamp_configured:
        $(foreach hook,$($(PKG)_PRE_CONFIGURE_HOOKS),$(call $(hook))$(sep))
        @$(call MESSAGE,"Configuring")
        $($(PKG)_CONFIGURE_CMDS)
        $(foreach hook,$($(PKG)_POST_CONFIGURE_HOOKS),$(call $(hook))$(sep))
        $(Q)touch $@

$(2)_TARGET_CONFIGURE =         $$($(2)_DIR)/.stamp_configured

$(1)-configure:         $(1)-patch $(1)-depends \
                        $$($(2)_TARGET_CONFIGURE)

$(1)-build:             $(1)-configure \
                        $$($(2)_TARGET_BUILD)

$(1)-install-target:    $(1)-build \
                        $$($(2)_TARGET_INSTALL_TARGET)

$(1)-install:           $(1)-install-staging $(1)-install-target $(1)-install-images

 

$(1):                   $(1)-install

every package/<package>/<package>.mk, there will be one statement:

$(eval $(autotools-package))

$(eval $(generic-package))

It owns dependency on each other:

if .stamp_configured file be removed, then $(1)-configure can't find its prerequisite it will call $$($(2)_TARGET_CONFIGURE)'s recipe, that is do the configure work.

if .stamp_configured file is not removed and not changed, then $(1)-configure find its prerequisite have existed, so it will not call $$($(2)_TARGET_CONFIGURE)'s recipe.

The reason why make works like this, can refer to cmake's manual 4.3 Types of prerequisite:

There are actually two different types of prerequisites understood byGNU make: normal prerequisites such as described in theprevious section, and order-only prerequisites. A normalprerequisite makes two statements: first, it imposes an order in whichrecipes will be invoked: the recipes for all prerequisites of a targetwill be completed before the recipe for the target is run. Second, itimposes a dependency relationship: if any prerequisite is newer thanthe target, then the target is considered out-of-date and must berebuilt.

that while .stamp_configured file not removed, it is same new as its target $(2)_TARGET_CONFIGURE, so not need rebuild. but if .stamp_configured file removed, it will be created and it is newer than its target $(2)_TARGET_CONFIGURE, so $$($(2)_TARGET_CONFIGURE)'s recipe will be executed.