Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 05/11] package/pkg-generic.mk: rework pkg_size logic with the "installed" step
Date: Sat, 2 May 2020 11:52:46 +0200	[thread overview]
Message-ID: <20200502115246.059d990e@windsurf.home> (raw)
In-Reply-To: <20200501204441.GA15673@scaer>

Hello,

Thanks for taking the time to review this stuff!

On Fri, 1 May 2020 22:44:41 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> I don't understand wy tht can't be achieved in the instrumentation hooks
> mechanism:
> 
>     $(if $(filter start-configure,$(1)-$(2)),\
>         $(call step_pkg_size_before,$(TARGET_DIR))\
>         $(call step_pkg_size_before,$(STAGING_DIR),-staging)\
>         $(call step_pkg_size_before,$(HOST_DIR),-host))
> 
>     $(if $(filter end-install,$(1)-$(2)),\
>         $(call step_pkg_size_after,$(TARGET_DIR))\
>         $(call step_pkg_size_after,$(STAGING_DIR),-staging)\
>         $(call step_pkg_size_after,$(HOST_DIR),-host))
> 
> Of course, it means you have to add a call the instrumentation hooks
> from the new 'install' step.

This wouldn't work for the configure step. See the code:

$(BUILD_DIR)/%/.stamp_configured:
	@$(call step_start,configure)
	@$(call MESSAGE,"Configuring")
	$(call prepare-per-package-directory,$($(PKG)_FINAL_DEPENDENCIES))

The hooks are called *before* we populate the per package directories.
But we need to capture the list of files *after* we populate the per
package directories.

In addition, I don't really understand why we use those global
instrumentation hooks within the generic infra itself. It is just a lot
clearer to me to make those function calls directly than to have this
indirection through hooks.

For me, it's like using hooks for the configure, build or install steps
of a generic package. For example, do we typically do:

ifeq ($(something),y)
define FOO_BUILD_THIS
	...
endef
endif

define FOO_BUILD_CMDS
	... do stuff ...
	$(FOO_BUILD_THIS)
endef

or this:

define FOO_BUILD_CMDS
	... do stuff ...
endef

ifeq ($(something),y)
define FOO_BUILD_THIS
	...
endef
FOO_POST_BUILD_HOOKS += FOO_BUILD_THIS
endef

We typically do the former, because there is no point in using hooks in
this situation. Hooks are useful to inject some logic to a step of
logic you don't have control over. When you have control over that step
of logic, hooks are kind of useless.

That being said, if you have a proposal to solve the ordering of things
in the configure step between the instrumentation hook and the
per-package directory population, I'm definitely fine with changing to
use instrumentation hooks.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2020-05-02  9:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-30  9:52 [Buildroot] [PATCH 00/11] Overwritten file detection, improvements to file listing logic Thomas Petazzoni
2020-04-30  9:52 ` [Buildroot] [PATCH 01/11] package/pkg-generic.mk: use $(PKG)_NAME in step_pkg_size_after Thomas Petazzoni
2020-04-30  9:52 ` [Buildroot] [PATCH 02/11] package/pkg-generic.mk: drop useless $(1) argument in step_pkg_size_{before, after} Thomas Petazzoni
2020-04-30  9:52 ` [Buildroot] [PATCH 03/11] package/pkg-generic.mk: introduce final 'install' step Thomas Petazzoni
2020-04-30  9:52 ` [Buildroot] [PATCH 04/11] package/pkg-generic.mk: create directories upfront in the configure step Thomas Petazzoni
2020-04-30  9:52 ` [Buildroot] [PATCH 05/11] package/pkg-generic.mk: rework pkg_size logic with the "installed" step Thomas Petazzoni
2020-05-01 20:44   ` Yann E. MORIN
2020-05-02  9:52     ` Thomas Petazzoni [this message]
2020-04-30  9:52 ` [Buildroot] [PATCH 06/11] package/pkg-generic.mk: exclude the staging sub-directory Thomas Petazzoni
2020-05-01 20:57   ` Yann E. MORIN
2020-04-30  9:52 ` [Buildroot] [PATCH 07/11] package/pkg-generic.mk: move pkg_size_{before, after} and check_bin_arch functions Thomas Petazzoni
2020-05-01 21:01   ` Yann E. MORIN
2020-04-30  9:52 ` [Buildroot] [PATCH 08/11] package/pkg-generic.mk: detect files overwritten in TARGET_DIR and HOST_DIR Thomas Petazzoni
2020-05-01 21:23   ` Yann E. MORIN
2020-07-24 19:53     ` Yann E. MORIN
2020-07-25  5:58       ` Peter Korsgaard
2020-07-25  7:13         ` Yann E. MORIN
2020-07-25  8:12           ` Peter Korsgaard
2020-04-30  9:52 ` [Buildroot] [PATCH 09/11] support/testing/infra: add log_file_path() function Thomas Petazzoni
2020-07-24 20:11   ` Yann E. MORIN
2020-04-30  9:52 ` [Buildroot] [PATCH 10/11] support/testing/tests: add test for check_bin_arch Thomas Petazzoni
2020-07-25 11:59   ` Yann E. MORIN
2020-04-30  9:52 ` [Buildroot] [PATCH 11/11] support/testing/tests: add test for file overwrite detection Thomas Petazzoni
2020-07-25 12:05   ` Yann E. MORIN
2020-07-23 20:54 ` [Buildroot] [PATCH 00/11] Overwritten file detection, improvements to file listing logic Yann E. MORIN

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200502115246.059d990e@windsurf.home \
    --to=thomas.petazzoni@bootlin.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox