Re: [Buildroot] [RFC PATCH 1/1] package/pkg-generic.mk: introduce pre/post target finalize hooks

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello James,

On Sat,  3 Aug 2024 13:38:32 -0400
James Knight <james.d.knight@live.com> wrote:

> Provides the ability for packages to register hooks in the finalization
> process before and after Buildroot performs its own final target
> changes. The pre-hook (`LIBFOO_TARGET_PRE_FINALIZE_HOOKS`) operates in
> the same manner as `LIBFOO_TARGET_FINALIZE_HOOKS` did before. The newly
> added post-hook (`LIBFOO_TARGET_POST_FINALIZE_HOOKS`) allows packages
> to perform target modifications after Buildroot applies changes such as
> rootfs overlay updates.
> 
> Signed-off-by: James Knight <james.d.knight@live.com>
> ---
> The following is a proposal for adding support for post-finalize hooks
> into the Buildroot framework. Been playing with using external package
> definitions to perform some post-build tweaks to some board
> configurations. While post-build scripts are a great way to perform any
> late-stage target manipulation, it would be nice to be able to define
> packages and register them into the menu system to make it easier to
> re-use shared tweaks across multiple board configuration (versus trying
> to add/stack post-build script paths into each configuration).
> 
> While `LIBFOO_TARGET_FINALIZE_HOOKS` worked for most cases, this occurs
> before Buildroot performs additional finalization changes (e.g. merged
> usr/). It would be nice to allow packages to perform their own
> finalization changes after Buildroot does the bulk of it's own
> finalization, but before post-build scripts are invoked.
> 
> If this change is considered, it appears the `luarocks.mk` package would
> also need to be updated (in addition to manual changes).

Thanks for proposing this. Obviously it raises a number of
questions/comments:

- My initial though was "but pre/post hooks only make sense when they
  are around a well-defined step, like download, extract, build, etc.,
  the target-finalize step is much more loosely defined". But in the
  end, perhaps we can consider target-finalize like a step.

- If we were to have PRE_FINALIZE_HOOKS and POST_FINALIZE_HOOKS, we
  should drop the TARGET_FINALIZE_HOOKS from all packages, otherwise
  the semantic is really unclear.

- Could give a specific example of something that cannot be using the
  existing TARGET_FINALIZE_HOOKS? I'm not talking about a theoretical
  example like "a user may want to...", but a really specific practical
  example you've encountered.

- Also, do we have some evidence that what we're doing as
  TARGET_FINALIZE_HOOKS today cannot be done at the point of the
  POST_FINALIZE_HOOKS that you are adding today?

Basically, I would like some really compelling evidence that we need
both hook points.

Thoughts?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot