u-boot.git/tools/buildman/toolchain.py, branch master Unnamed repository; edit this file 'description' to name the repository. python: Use and refer to the venv module rather than virtualenv 2025-04-24T21:37:27+00:00 Tom Rini trini@konsulko.com 2025-04-15T18:10:26+00:00 efd00b03455644b18eaf2b6dcd07f6d55b95b39e Using some form of sandbox with Python modules is a long standing best practice with the language. There are a number of ways to have a Python sandbox be created. At this point in time, it seems the Python community is moving towards using the "venv" module provided with Python rather than a separate tool. To match that we make the following changes: - Refer to a "Python sandbox" rather than virtualenv in comments, etc. - Install the python3-venv module in our container and not virtualenv. - In our CI files, invoke "python -m venv" rather than "virtualenv". - In documentation, tell users to install python3-venv and not virtualenv. Signed-off-by: Tom Rini <trini@konsulko.com> 
Using some form of sandbox with Python modules is a long standing best
practice with the language. There are a number of ways to have a Python
sandbox be created. At this point in time, it seems the Python community
is moving towards using the "venv" module provided with Python rather
than a separate tool. To match that we make the following changes:

- Refer to a "Python sandbox" rather than virtualenv in comments, etc.
- Install the python3-venv module in our container and not virtualenv.
- In our CI files, invoke "python -m venv" rather than "virtualenv".
- In documentation, tell users to install python3-venv and not
  virtualenv.

Signed-off-by: Tom Rini <trini@konsulko.com>
buildman: Update to grabbing gcc-14.2.0 toolchains by default 2025-04-15T17:55:17+00:00 Tom Rini trini@konsulko.com 2025-04-11T17:04:06+00:00 05a2b6984159e83d91420af283dd204bdbe07d65 With the switch to using GCC 14.2.0 in commit 001bac5f16ad ("Dockerfile: Update to gcc-14.2.0 and clang-18") in CI, we should make buildman match this. Signed-off-by: Tom Rini <trini@konsulko.com> 
With the switch to using GCC 14.2.0 in commit 001bac5f16ad ("Dockerfile:
Update to gcc-14.2.0 and clang-18") in CI, we should make buildman match
this.

Signed-off-by: Tom Rini <trini@konsulko.com>
u_boot_pylib: Add a function to run a single command 2025-03-04T19:31:49+00:00 Simon Glass sjg@chromium.org 2025-02-03T16:26:45+00:00 3d094ce28a22690c3d672988af5f161310822603 Add a helper to avoid needing to use a list within a list for this simple case. Update existing users of runpipe() to use this where possible. Signed-off-by: Simon Glass <sjg@chromium.org> 
Add a helper to avoid needing to use a list within a list for this
simple case.

Update existing users of runpipe() to use this where possible.

Signed-off-by: Simon Glass <sjg@chromium.org>
buildman: Support a tilde to represent the home directory 2024-11-19T16:04:47+00:00 Simon Glass sjg@chromium.org 2024-11-08T15:23:48+00:00 e2ca257287a557bff762cedd630c2664ce8ddcc5 It is convenient to use ~ to represent the home directory in the settings file. Add support for this. Signed-off-by: Simon Glass <sjg@chromium.org> 
It is convenient to use ~ to represent the home directory in the
settings file. Add support for this.

Signed-off-by: Simon Glass <sjg@chromium.org>
buildman: Correct logic for adding a toolchain 2024-11-19T16:04:47+00:00 Simon Glass sjg@chromium.org 2024-11-08T15:23:47+00:00 eae1eb0e860fe6380906cace0877ef956683c615 If the toolchain is bad, it should not be added. Correct the logic for this. Signed-off-by: Simon Glass <sjg@chromium.org> 
If the toolchain is bad, it should not be added. Correct the logic for
this.

Signed-off-by: Simon Glass <sjg@chromium.org>
buildman: Correct some warnings about regex strings 2024-10-18T20:10:22+00:00 Simon Glass sjg@chromium.org 2024-09-21T17:57:57+00:00 02eb9f166573009f576133a15d6323ff4ab479b1 With Python 3.12 some warnings have cropped up. Fix them. Signed-off-by: Simon Glass <sjg@chromium.org> 
With Python 3.12 some warnings have cropped up. Fix them.

Signed-off-by: Simon Glass <sjg@chromium.org>
buildman/toolchain.py: do not set CROSS_COMPILE for sandbox 2024-09-24T19:41:20+00:00 Jerome Forissier jerome.forissier@linaro.org 2024-09-11T09:58:14+00:00 0c2d7ad3e0635a52d291035d9044922ef7b19e7a When building for sandbox, self.cross is empty. In MakeEnvironment(), CROSS_COMPILE is defined to be self.cross (with or without a full path), optionally prefixed by the toolchain wrapper defined in ~/.buildman. This is fine when self.cross is not empty, but it doesn't make sense when it is: - Either there is no wrapper and we end up with an empty CROSS_COMPILE which is the same as not defining it (the host compiler will be used), - Or there is a wrapper and CROSS_COMPILE will contain only the wrapper which obviously is not a valid compiler, hence an error. Test case: $ sudo apt install ccache $ grep -q toolchain-wrapper ~/.buildman || \ printf "[toolchain-wrapper]\nwrapper = ccache\n" >>~/.buildman $ make mrproper $ ./tools/buildman/buildman sandbox_noinst $ ./tools/buildman/buildman sandbox_noinst Building current source for 1 boards (1 thread, 24 jobs per thread) sandbox: + sandbox_noinst +arch/sandbox/lib/reloc_sandbox_efi.c:10:15: error: operator '==' has no left operand + 10 | #if HOST_ARCH == HOST_ARCH_X86_64 + | ^~ [...] The GetEnvArgs function is modified too, since the VAR_CROSS_COMPILE case has the same issue. In tools/buildman/test.py, testGetEnvArgs is extended and testMakeEnvironment is added. They check the 'arm' and 'sandbox' toolchains, with and without a wrapper. Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> 
When building for sandbox, self.cross is empty.

In MakeEnvironment(), CROSS_COMPILE is defined to be self.cross (with
or without a full path), optionally prefixed by the toolchain wrapper
defined in ~/.buildman. This is fine when self.cross is not empty, but
it doesn't make sense when it is:
- Either there is no wrapper and we end up with an empty CROSS_COMPILE
which is the same as not defining it (the host compiler will be used),
- Or there is a wrapper and CROSS_COMPILE will contain only the wrapper
which obviously is not a valid compiler, hence an error.

Test case:

 $ sudo apt install ccache
 $ grep -q toolchain-wrapper ~/.buildman || \
     printf "[toolchain-wrapper]\nwrapper = ccache\n" >>~/.buildman
 $ make mrproper
 $ ./tools/buildman/buildman sandbox_noinst
 $ ./tools/buildman/buildman sandbox_noinst
 Building current source for 1 boards (1 thread, 24 jobs per thread)
    sandbox:  +   sandbox_noinst
 +arch/sandbox/lib/reloc_sandbox_efi.c:10:15: error: operator '==' has no left operand
 +   10 | #if HOST_ARCH == HOST_ARCH_X86_64
 +      |               ^~
[...]

The GetEnvArgs function is modified too, since the VAR_CROSS_COMPILE
case has the same issue.

In tools/buildman/test.py, testGetEnvArgs is extended and
testMakeEnvironment is added. They check the 'arm' and 'sandbox'
toolchains, with and without a wrapper.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
buildman: Support building within a Python venv 2024-09-06T18:45:54+00:00 Simon Glass sjg@chromium.org 2024-08-15T19:57:44+00:00 d0f74bd417daf6492975ce346843ba0767caf51c The Python virtualenv tool sets up a few things in the environment, 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> 
The Python virtualenv tool sets up a few things in the environment,
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>
Revert "buildman: Always use the full path in CROSS_COMPILE" 2024-07-08T15:12:34+00:00 Tom Rini trini@konsulko.com 2024-07-05T20:34:07+00:00 e13fcae3fce8b2c4db86339c9e8bafdd403f22b5 There are operations in buildman that result in running the cross-tools (such as performing size checks) and now that we have not modified PATH to know where our tools are, these operations fail. This reverts commit 6c0a3cf75f72370deec3ee516a9dd377397af207. Signed-off-by: Tom Rini <trini@konsulko.com> 
There are operations in buildman that result in running the cross-tools
(such as performing size checks) and now that we have not modified PATH
to know where our tools are, these operations fail.

This reverts commit 6c0a3cf75f72370deec3ee516a9dd377397af207.

Signed-off-by: Tom Rini <trini@konsulko.com>
buildman: Always use the full path in CROSS_COMPILE 2024-07-03T06:36:33+00:00 Simon Glass sjg@chromium.org 2024-06-23T17:56:20+00:00 6c0a3cf75f72370deec3ee516a9dd377397af207 The feature to set the toolchain path does not seem to be needed. It causes problems with venv (see [1]). Let's remove it. Add some tests while we are here. It does not look like any docs changes are needed for this. [1] https://patchwork.ozlabs.org/project/uboot/patch/20240621131423.2363294-6-sjg@chromium.org/ Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Tom Rini <trini@konsulko.com> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com> 
The feature to set the toolchain path does not seem to be needed. It
causes problems with venv (see [1]). Let's remove it.

Add some tests while we are here.

It does not look like any docs changes are needed for this.

[1] https://patchwork.ozlabs.org/project/uboot/patch/20240621131423.2363294-6-sjg@chromium.org/

Signed-off-by: Simon Glass <sjg@chromium.org>
Suggested-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>