From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Gregor Haas <gregorhaas1997@gmail.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/1] package/bmap-tools: add dependency on python-six
Date: Thu, 24 Aug 2023 21:20:16 +0200 [thread overview]
Message-ID: <20230824192016.GA3722679@scaer> (raw)
In-Reply-To: <20230822214755.1af65bb4@windsurf>
Thomas, All,
On 2023-08-22 21:47 +0200, Thomas Petazzoni spake thusly:
> On Mon, 14 Aug 2023 14:52:33 -0700
> Gregor Haas <gregorhaas1997@gmail.com> wrote:
> For the host package, I can indeed reproduce the problem. But I think
> the issue really is that in the final $(HOST_DIR), we keep the shebang
> of the Python interpreter pointing to the per-package directory.
> Indeed, my reasoning is that otherwise we will have many similar
> problems with other packages, as this is breaking a fundamental
> assumption in Buildroot.
>
> I'm thinking about something like this:
>
> diff --git a/Makefile b/Makefile
> index f0ff9a1480..00ce64ab15 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -713,6 +713,15 @@ STAGING_DIR_FILES_LISTS = $(sort $(wildcard $(BUILD_DIR)/*/.files-list-staging.t
> host-finalize: $(PACKAGES) $(HOST_DIR) $(HOST_DIR_SYMLINK)
> @$(call MESSAGE,"Finalizing host directory")
> $(call per-package-rsync,$(sort $(PACKAGES)),host,$(HOST_DIR))
> +ifeq ($(BR2_PER_PACKAGE_DIRECTORIES),y)
> + $(Q)grep --binary-files=without-match -lrZ '$(PER_PACKAGE_DIR)/[^/]\+/host' $(HOST_DIR) \
> + |while read -d '' f; do \
> + file -b --mime-type "$${f}" | grep -q '^text/' || continue; \
> + printf '%s\0' "$${f}"; \
> + done \
> + |xargs -0 --no-run-if-empty \
> + $(SED) 's:$(PER_PACKAGE_DIR)/[^/]\+/host:$(HOST_DIR):g'
> +endif
>
> .PHONY: staging-finalize
> staging-finalize: $(STAGING_DIR_SYMLINK)
>
> Yann, what do you think? (Logic is taken from package/pkg-generic.mk,
> which does the conversion from per-package directories of dependencies
> to the per-package directory of the package being built, the logic here
> is similar, but we switch from the per-package directories to the
> global host directory)
Then we want to avoid code duplication, why can't we re-use the existing
PPD_FIXUP_PATHS macro?
It might need a bit of tweaking, though:
- first, we only need to fixup paths in $(HOST_DIR), and this is
already what we are doing.
- second, we only need to fix path for host tools, libs et al., so
that they can still run, and paths for staging/ libs et al., so that
we can link against.
However, that second point is not what we are doing, as we are tweaking
everything at the root of the PPD:
$(SED) 's:$(PER_PACKAGE_DIR)/[^/]\+/:$(PER_PACKAGE_DIR)/$($(PKG)_NAME)/:g'
Furthermore, staging/ is a sub-directory of host/ and we already account
for that as we are only grepping in $(HOST_DIR). But with the sed, we
replace a shaloower path than HOST_DIR.
So I think we can change the existing PPD_FIXUP_PATHS to:
define PPD_FIXUP_PATHS
$(Q)grep --binary-files=without-match -lrZ '$(PER_PACKAGE_DIR)/[^/]\+/' $(HOST_DIR) \
|while read -d '' f; do \
file -b --mime-type "$${f}" | grep -q '^text/' || continue; \
printf '%s\0' "$${f}"; \
done \
|xargs -0 --no-run-if-empty \
- $(SED) 's:$(PER_PACKAGE_DIR)/[^/]\+/:$(PER_PACKAGE_DIR)/$($(PKG)_NAME)/:g'
+ $(SED) 's:$(PER_PACKAGE_DIR)/[^/]\+/host/:$(HOST_DIR)/:g'
endef
And then, we can expand that macro in both contexts: PPD_rsync and
target-finalize.
Thoughts?
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2023-08-24 19:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 21:52 [Buildroot] [PATCH 1/1] package/bmap-tools: add dependency on python-six Gregor Haas
2023-08-22 19:47 ` Thomas Petazzoni via buildroot
2023-08-23 20:17 ` Gregor Haas
2023-08-23 21:04 ` Thomas Petazzoni via buildroot
2023-08-24 19:20 ` Yann E. MORIN [this message]
2023-12-21 22:17 ` Gregor Haas
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=20230824192016.GA3722679@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@buildroot.org \
--cc=gregorhaas1997@gmail.com \
--cc=thomas.petazzoni@bootlin.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.