| Age | Commit message (Collapse) | Author |
|---|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
It is convenient to use ~ to represent the home directory in the
settings file. Add support for this.
Signed-off-by: Simon Glass <[email protected]>
|
|
If the toolchain is bad, it should not be added. Correct the logic for
this.
Signed-off-by: Simon Glass <[email protected]>
|
|
With Python 3.12 some warnings have cropped up. Fix them.
Signed-off-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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/[email protected]/
Signed-off-by: Simon Glass <[email protected]>
Suggested-by: Tom Rini <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
Reviewed-by: Andrejs Cainikovs <[email protected]>
|
|
Fix 'Thie' and capitalise 'unicode'.
Signed-off-by: Simon Glass <[email protected]>
Suggested-by: Heinrich Schuchardt <[email protected]>
|
|
The latest kernel.org toolchains for gcc are now 13.2.0, so upgrade to
that.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
Convert this file to snake case and update all files which use it.
Signed-off-by: Simon Glass <[email protected]>
|
|
As this is the current version of the public cross toolchains we use,
upgrade to this now.
Suggested-by: Alexey Brodkin <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
Acked-by: Alexey Brodkin <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Signed-off-by: Tom Rini <[email protected]>
|
|
The toolchain test causes the settings file to be overwritten, which is
annoying for local development. Fix it by passing None as the filename.
Signed-off-by: Simon Glass <[email protected]>
|
|
The previous attempt at fixing this broke the normal usage of the -A
flag.
At present, 'buildman -A sandbox' adds the path containing the
toolchain. We can assume that this is in the path and we don't want to
set CROSS_COMPILE=/bin/
Change this to align with what MakeEnvironment() does, but only for
sandbox boards.
Signed-off-by: Simon Glass <[email protected]>
|
|
This reverts commit bd0a548ad4a155fec29473d4cc8e135832926973.
Signed-off-by: Simon Glass <[email protected]>
|
|
At present, 'buildman -A sandbox' adds the path containing the
toolchain at present. We can assume that this is in the path and
we don't want to set CROSS_COMPILE=/bin/ so change this to align
with what MakeEnvironment() does.
Signed-off-by: Simon Glass <[email protected]>
|
|
The patman directory has a number of modules which are used by other tools
in U-Boot. This makes it hard to package the tools using pypi since the
common files must be copied along with the tool that uses them.
To address this, move these files into a new u_boot_pylib library. This
can be packaged separately and listed as a dependency of each tool.
Signed-off-by: Simon Glass <[email protected]>
|
|
The readme file for buildman is called buildman.rst.
Signed-off-by: Heinrich Schuchardt <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Update the toolchain list to be first 12.2.0 and second 11.1.0 and
that's it.
Cc: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
We have a module called 'board'. Sometimes buildman uses 'brd' as an
instance variable but sometimes it uses 'board', which is confusing and
can mess with the module handling. Update the code to use 'brd'
consistently, making it easier for tools to determine when the module
is being referenced.
Signed-off-by: Simon Glass <[email protected]>
|
|
This method has the same name as its class which is confusing. It is also
annoying when searching the code.
It builds a string with a colour, so rename it to build().
Signed-off-by: Simon Glass <[email protected]>
|
|
Convert this file to snake case and update all files which use it.
Signed-off-by: Simon Glass <[email protected]>
|
|
Convert this file to snake case and update all files which use it.
Signed-off-by: Simon Glass <[email protected]>
|
|
Reverse the order of the return tuple, so that the filename is first.
This seems more obvious than putting the temporary directory first.
Correct a bug that leaves a space on the final line.
Allow the caller to control the name of the temporary directory.
Signed-off-by: Simon Glass <[email protected]>
|
|
This function is handy for binman as well. Move it into the shared 'tools'
module.
Signed-off-by: Simon Glass <[email protected]>
|
|
While CI has been using gcc-11.1.0 for a long time, we have not updated
buildman to match. Correct this omission.
Signed-off-by: Tom Rini <[email protected]>
|
|
At present we sometimes see problems in gitlab where the environment has
0x80 characters or sequences which are not valid UTF-8.
Avoid this by using bytes for the environment, both internal to buildman
and when writing out the 'env' file. Add a test to make sure this works
as expected.
Reported-by: Marek Vasut <[email protected]>
Fixes: e5fc79ea718 ("buildman: Write the environment out to an 'env' file")
Signed-off-by: Simon Glass <[email protected]>
|
|
At present patman sets the python path on startup so that it can access
the libraries it needs. If we convert to use absolute imports this is not
necessary.
Move patman to use absolute imports. This requires changes in tools which
use the patman libraries (which is most of them).
Signed-off-by: Simon Glass <[email protected]>
|
|
At present buildman sets the python path on startup so that it can access
the libraries it needs. If we convert to use absolute imports this is not
necessary.
Move buildman to use absolute imports. Also adjust moveconfig.py too since
it uses some buildman modules and cannot work without this.
Signed-off-by: Simon Glass <[email protected]>
|
|
This adds support to fetch gcc 9.2.0 toolchains.
Signed-off-by: Bin Meng <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
At kernel.org aarch64 toolchains are published in folder
arm64. Fix the URL for that case, so that we can fetch
toolchains on aarch64 machines.
Signed-off-by: Matthias Brugger <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Sometimes it is useful for external tools to use buildman to provide the
toolchain information. Add an -a option which shows the value to use for
the ARCH environment variable, and -A which does the same for
CROSS_COMPILE
Signed-off-by: Simon Glass <[email protected]>
|
|
The parser responsible for the '[make-flags]' section in
the '.buildman' settings file is currently not able to
handle quoted strings, as given in the sample bellow:
[make-flags]
qemu_arm=HOSTCC="cc -isystem /add/include" HOSTLDFLAGS="-L/add/lib"
This patch replaces the simple string splitter based on the <space>
delimiter with a regex tokenizer that preserves spaces inside double
quoted strings.
Signed-off-by: Cristian Ciocaltea <[email protected]>
|
|
Convert buildman to Python 3 and make it use that, to meet the 2020
deadline.
Signed-off-by: Simon Glass <[email protected]>
|
|
This function has tabs instead of spaces. Fix it.
Signed-off-by: Simon Glass <[email protected]>
|
|
Add a -O option which allows building with clang.
Signed-off-by: Simon Glass <[email protected]>
|
|
Unfortunately, for some releases the kernel.org toolchain tarball names adhere
to the following pattern:
<hostarch>-gcc-<ver>-nolib-<targetarch>-<type>.tar.xz
e.g.:
x86_64-gcc-8.1.0-nolibc-aarch64-linux.tar.xz
while others use the following pattern:
<hostarch>-gcc-<ver>-nolib_<targetarch>-<type>.tar.xz
e.g.:
x86_64-gcc-7.3.0-nolibc_aarch64-linux.tar.xz
Notice that the first pattern has dashes throughout, while the second has
dashes throughout except just before the target architecture which has an
underscore.
The "dash throughout" versions from kernel.org are:
8.1.0, 6.4.0, 5.5.0, 4.9.4, 4.8.5, 4.6.1
while the "dash and underscore" versions from kernel.org are:
7.3.0, 4.9.0, 4.8.0, 4.7.3, 4.6.3, 4.6.2, 4.5.1, 4.2.4
This tweak allows the code to handle both versions. Note that this tweak also
causes the architecture parsing to get confused and find the following two
bogus architectures, "2.0" and "64", which are explicitly checked for, and
removed.
Signed-off-by: Trevor Woerner <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Change single quotes to double quotes:
Signed-off-by: Simon Glass <[email protected]>
|
|
The hexagon toolchain (4.6.1) from kernel.org, for example, was packaged in
a way that is different from most toolchains. The first entry when unpacking
most toolchain tarballs is:
gcc-<version>-nolib/<targetarch>-<system>
e.g.:
gcc-8.1.0-nolibc/aarch64-linux/
The first entry of the hexagon toolchain, however, is:
gcc-4.6.1-nolibc/
This causes the buildman logic in toolchain.py::ScanPath() to not be able to
find the "*gcc" executable since it looks in gcc-4.6.1-nolib/{.|bin|usr/bin}
instead of gcc-4.6.1/hexagon-linux/{.|bin|usr/bin}. Therefore when buildman
tries to download a set of toolchains that includes hexagon, the script fails.
This update takes the second line of the tarball unpacking (which works for
all the toolchains I've tested from kernel.org) and parses it to take the
first two elements, separated by '/'. It makes this logic a bit more robust.
Signed-off-by: Trevor Woerner <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add support for gcc versions 7.3.0, 6.4.0 and 4.9.4.
Also use a regex for matching the tarball names. Some gcc versions
use '-ARCH-' instead of '_ARCH-'.
As part of this, we switch TravisCI to also using these toolchains for
all platforms.
Signed-off-by: Daniel Schwierzeck <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
|
|
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <[email protected]>
|
|
Build tools like Make, gcc or binutils support localized output
or unicode encoded output dependent on the default system locale.
This is not useful for buildman, where we want reproducible
warning or error messages or where the output of binutils is
further processed.
Signed-off-by: Daniel Schwierzeck <[email protected]>
|
|
Many toolchains for ARM use the 'gnueabihf' suffix rather than just
'gnueabi', so allow these to be used, but with a lower priority than
'gnueabi' ones.
Cc: Simon Glass <[email protected]>
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Now we can use compiler wrapper such as ccache or distcc for buildman.
Signed-off-by: York Sun <[email protected]>
CC: Simon Glass <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
The current code for setting up the toolchain config always writes the new
paths to an item called 'toolchain'. This means that it will overwrite any
existing toolchain item with the same name. In practice, this means that:
buildman --fetch-arch all
will fetch all toolchains, but only the path of the final one will be added
to the config. This normally works out OK, since most toolchains are the
same version (e.g. gcc 4.9) and will be found on the same path. But it is
not correct and toolchains for archs which don't use the same version will
not function as expected.
Adjust the code to use a complete glob of the toolchain path.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
The function comment should say 'buildman'. Fix it.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
Use colour to make it easier to see what is going on. Also print a message
before downloading a new toolchain. Mention --fetch-arch in the message that
is shown when there are no available toolchains, since this is the quickest
way to resolve the problem.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
When there are no toolchains a warning is printed. But in some cases this is
confusing, such as when the user is fetching new toolchains.
Adjust the function to supress the warning in this case.
Signed-off-by: Simon Glass <[email protected]>
|
