From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
Heinrich Schuchardt <xypron.glpk@gmx.de>,
Quentin Schulz <quentin.schulz@cherry.de>
Subject: Re: [PATCH 3/5] buildman: Support building within a Python venv
Date: Thu, 20 Jun 2024 08:32:32 -0600 [thread overview]
Message-ID: <20240620143232.GM68077@bill-the-cat> (raw)
In-Reply-To: <20240620131937.1130446-4-sjg@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
On Thu, Jun 20, 2024 at 07:19:35AM -0600, Simon Glass wrote:
> The Python virtualenv tool sets up a few things in the envronment,
> putting its path first in the PATH environment variable and setting up
> a sys.prefix different from the sys.base_prefix value.
>
> At present buildman puts the toolchain path first in PATH so that it can
> be found easily during the build. For sandbox this causes problems since
> /usr/bin/gcc (for example) results in '/usr/bin' being prepended to the
> PATH variable. As a result, the venv is partially disabled.
>
> The result is that sandbox builds within a venv ignore the venv, e.g.
> when looking for packages.
>
> Correct this by detecting the venv and adding the toolchain path after
> the venv path.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
Why are we using PATH at all in this case? Shouldn't we just be setting
CROSS_COMPILE=/full/path/to/the/prefix ?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2024-06-20 14:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 13:19 [PATCH 0/5] Add Binman code-coverage test to CI Simon Glass
2024-06-20 13:19 ` [PATCH 1/5] Dockerfile: Add python3-coverage Simon Glass
2024-06-20 14:30 ` Tom Rini
2024-06-20 13:19 ` [PATCH 2/5] Dockerfile: Add python3-pycryptodome Simon Glass
2024-06-20 13:19 ` [PATCH 3/5] buildman: Support building within a Python venv Simon Glass
2024-06-20 13:38 ` Heinrich Schuchardt
2024-06-20 23:05 ` Simon Glass
2024-06-20 14:32 ` Tom Rini [this message]
2024-06-20 23:05 ` Simon Glass
2024-06-20 23:30 ` Tom Rini
2024-06-21 14:57 ` Simon Glass
2024-06-21 15:22 ` Tom Rini
2024-06-21 18:19 ` Simon Glass
2024-06-21 19:26 ` Tom Rini
2024-06-21 19:39 ` Simon Glass
2024-06-21 20:48 ` Tom Rini
2024-06-20 13:19 ` [PATCH 4/5] u_boot_pylib: Use correct coverage tool within venv Simon Glass
2024-06-20 13:19 ` [PATCH 5/5] CI: Run code-coverage test for Binman Simon Glass
2024-06-20 14:34 ` Tom Rini
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=20240620143232.GM68077@bill-the-cat \
--to=trini@konsulko.com \
--cc=Alexey.Brodkin@synopsys.com \
--cc=quentin.schulz@cherry.de \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.de \
/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.