From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 08/18] package/pkg-generic.mk: move python fixup to generic package infrastructure
Date: Wed, 7 Jul 2021 22:12:57 +0200 [thread overview]
Message-ID: <20210707201257.GB410642@scaer> (raw)
In-Reply-To: <20210707144915.2db26f79@bootlin.com>
Herv?, Arnout, All,
On 2021-07-07 14:49 +0200, Herve Codina spake thusly:
> On Wed, 7 Jul 2021 14:21:16 +0200
> Arnout Vandecappelle <arnout@mind.be> wrote:
> > > These finds are now called for all packages and .../lib/python* can be not
> > > present. In this case, find fails.
OK, I see.
However, the commit log was lacking these explanations, because the
change is not simply "the python fixup is moved to the generic package
infrastructure", because the fixups had to be adapted.
> > A simpler way of doing that would be:
> > $(if $(wildcard $(HOST_DIR)/lib/python* $(STAGING_DIR)/usr/lib/python*),
> > $(Q)find $(HOST_DIR)/lib/python* $(STAGING_DIR)/usr/lib/python*
> I think this does not solve the problem.
> find fails if at least one of the 2 paths are not present.
>
> Something like this (not tested) is needed.
>
> $(if $(wildcard $(HOST_DIR)/lib/python* $(STAGING_DIR)/usr/lib/python*),
> $(Q)find $(wildcard $(HOST_DIR)/lib/python* $(STAGING_DIR)/usr/lib/python*)
Yes, this would keep the pre-existing behaviour.
However, I think the traditional way we usually do that would be with a
foreach:
$(foreach dir, $(wildcard $(HOST_DIR)/lib/python* $(STAGING_DIR)/usr/lib/python*), \
$(Q)find $(dir) -name "_sysconfigdata*.py" -print0 \
|xargs -0 --no-run-if-empty \
$(SED) "s:$(PER_PACKAGE_DIR)/[^/]\+/:$(PER_PACKAGE_DIR)/$($(PKG)_NAME)/:g"
$(Q)find $(dir) -name "_sysconfigdata*.pyc" -delete
)
And thus you're back to a basic, non-parameterised macro that can be
used as a POST_PREPARE_HOOK. Wee! :-)
Note: optimisation: we should be able to use a single find call to do
both, though:
$(foreach dir, $(wildcard $(HOST_DIR)/lib/python* $(STAGING_DIR)/usr/lib/python*), \
$(Q)find $(dir) \( -name "_sysconfigdata*.pyc" -delete \) \
-o \( -name "_sysconfigdata*.py" -print0 \) \
|xargs -0 --no-run-if-empty \
$(SED) 's:$(PER_PACKAGE_DIR)/[^/]\+/:$(PER_PACKAGE_DIR)/$($(PKG)_NAME)/:g'
)
Maybe the groupings '\( ... \)' are superfluous. Adapt appropriately...
> > > This assumes:
> > > (1) python stuff will not install anything in $(STAGING_DIR)/lib/python*
> > This you can safely assume.
Well, a package that would install its python bindings in /lib/python*
would anyway break at runtime, so this package would need to eb fixed to
install in /usr/lib/python*
So yes, nothing to look for in staging/lib/python*.
> > > (2) $(HOST_DIR)/usr will always be a symlink to $(HOST_DIR)/.
> > Although for now you can assume this, ideally we would like to have the
> > possibility to get rid of the usr->. symlink. So if you can avoid relying on it
> > it would be better.
> Right.
> Assuming, the symlink not present, can we be sure that host python stuff will be
> installed only in $(HOST_DIR)/lib/python* ?
I think, as Arnout said, that the usr symlink will always be present. So
we can also safely assume that there is nothing to look for in
host/usr/lib/python* either, because:
1) that would have already been found in host/lib/python*
2) that would also probably not work if usr was not a symlink, because
our host python would not look there to find modules anyway
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. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2021-07-07 20:12 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-06 14:24 [Buildroot] [PATCH v2 00/18] Overwritten file detection and fixes, one more step to TLP build Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 01/18] package/e2fsprogs: fix fsck overwrite in HOST_DIR Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 02/18] package/pkg-generic.mk: Remove Info documents dir entry Herve Codina
2021-07-06 19:25 ` Yann E. MORIN
2021-07-06 14:24 ` [Buildroot] [PATCH v2 03/18] package/pkg-generic.mk: perform .la files fixup in per-package HOST_DIR Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 04/18] package/pkg-generic: add post-prepare hooks Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 05/18] package/apr-util: use post-prepare hook Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 06/18] package/apache: move APACHE_FIXUP_APR_LIBTOOL to " Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 07/18] package/pkg-python: remove _sysconfigdata*.pyc files when _sysconfigdata*.py are changed Herve Codina
2021-07-06 19:29 ` Yann E. MORIN
2021-07-06 14:24 ` [Buildroot] [PATCH v2 08/18] package/pkg-generic.mk: move python fixup to generic package infrastructure Herve Codina
2021-07-06 19:50 ` Yann E. MORIN
2021-07-06 21:22 ` Yann E. MORIN
2021-07-07 11:48 ` Herve Codina
2021-07-07 12:21 ` Arnout Vandecappelle
2021-07-07 12:49 ` Herve Codina
2021-07-07 14:28 ` Arnout Vandecappelle
2021-07-07 20:12 ` Yann E. MORIN [this message]
2021-07-08 15:38 ` Herve Codina
2021-07-08 20:26 ` Yann E. MORIN
2021-07-09 6:48 ` Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 09/18] package/owfs: remove Python sysconfigdata fixup Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 10/18] package/pkg-generic.mk: detect files overwritten in TARGET_DIR and HOST_DIR Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 11/18] package/pkg-generic.mk: generate final rsync exclude file list Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 12/18] Makefile: rsync global {TARGET, HOST}_DIR using exclusion " Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 13/18] Makefile: breaks hardlinks in global {TARGET, HOST}_DIR on per-package build Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 14/18] package/pkg-generic.mk: fix per-package <pkg>-{reconfigure, rebuild, reinstall} Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 15/18] package/pkg-generic.mk: remove .files-final-rsync.before temporary file Herve Codina
2021-07-06 14:24 ` [Buildroot] [PATCH v2 16/18] support/testing/infra: add log_file_path() function Herve Codina
2021-07-06 14:25 ` [Buildroot] [PATCH v2 17/18] support/testing/tests: add test for check_bin_arch Herve Codina
2021-07-06 20:20 ` Yann E. MORIN
2021-07-06 21:25 ` Yann E. MORIN
2021-07-07 12:07 ` Herve Codina
2021-07-06 14:25 ` [Buildroot] [PATCH v2 18/18] support/testing/tests: add test for file overwrite detection Herve Codina
2021-07-06 21:19 ` [Buildroot] [PATCH v2 00/18] Overwritten file detection and fixes, one more step to TLP build 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=20210707201257.GB410642@scaer \
--to=yann.morin.1998@free.fr \
--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