When IDE mode is enabled (-I), warnings are not shown because:
1. The process_result() function only shows output in verbose mode,
not IDE mode
2. When there are warnings (stderr output), the build is considered
"failed" and retried. The retry finds the object files already up
to date from the first build, so make does not recompile them and
produces no warnings. The second result (with empty stderr) then
overwrites the first, losing the warnings.
Fix this by:
- Adding IDE mode handling in process_result() to write stderr directly
- Changing the retry logic to only retry on actual failures
(return_code != 0), not on warnings
Fixes: 6a30a2666008 ("buildman: Support running from an IDE")
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
The previous fix using -T4 is insufficient because queue-based job
distribution does not guarantee one board per thread. Even with 4
threads and 4 boards, a faster thread can finish its board and grab
another from the queue, causing .config to leak between boards in
the same thread's work directory.
Fix by using -P (per-board-out-dir) which gives each board its own
output directory, completely preventing .config leakage regardless
of thread scheduling.
Fixes: 17618b5975 ("buildman: Fix flaky test_kconfig_change test")
Co-developed-by: Claude Opus 4.5 <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
When CI has fewer CPUs than boards, one thread may process multiple
boards. The .config from the first board persists in the thread's work
directory, causing kconfig_changed_since() to return True for the next
board's first commit, triggering an extra reconfig.
Fix by forcing -T4 to ensure each board gets its own thread with an
isolated work directory.
Co-developed-by: Claude Opus 4.5 <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Exclude tools/qconfig.py from coverage since it's a separate tool with
its own tests. Add allow_failures for core buildman modules that don't
have 100% test coverage yet (builder.py, builderthread.py, cfgutil.py,
control.py, toolchain.py).
This fixes the --coverage test returning error code 1.
Co-developed-by: Claude Opus 4.5 <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Add automatic detection of Kconfig and defconfig file changes to trigger
reconfiguration. When any Kconfig* file or the board's defconfig is newer
than the board's .config file, buildman forces a reconfigure even if the
build was previously successful.
This is enabled by default and can be disabled with -Z/--no-kconfig-check.
Co-developed-by: Claude Opus 4.5 <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Add a new test_bsettings.py with 12 tests to achieve 100% coverage for
bsettings.py
Series-to: concept
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
Series-links: 1:86
Allow users to specify multiple config adjustments in a single -a
argument using commas. This is more convenient than repeating -a
multiple times.
Examples:
buildman -a FOO,~BAR
buildman -a FOO,~BAR -a BAZ=123
Add tests to verify comma-separated values work correctly.
Co-developed-by: Claude <noreply@anthropic.com>
Signed-off-by: Simon Glass <simon.glass@canonical.com>
If CROSS_COMPILE is set in the environment passed to buildman,
testMakeEnvironment() fails. Fix this by removing the variable before
starting the test.
Signed-off-by: Simon Glass <sjg@chromium.org>
If CPP is set (e.g. to 'gcc -E') buildman currently gives an error. Add
a little more logic to handle this case.
Signed-off-by: Simon Glass <sjg@chromium.org>
If DTC happens to be set in the environment provided to buildman itself,
this test currently fails. Fix it by removing any DTC variable before
starting the test.
Signed-off-by: Simon Glass <sjg@chromium.org>
Adjust the build logic to automatically deal with adding config
fragments to an existing board, to fully support the -X option.
Signed-off-by: Simon Glass <sjg@chromium.org>
Provide a new -X option which uses any available .buildman files to
augment the list of boards supported by U-Boot with 'extended boards',
which consist of a base board with one or more config fragments.
Signed-off-by: Simon Glass <sjg@chromium.org>
We wish to support .buildman files in the config/ directory which can
associate boards with config fragments. Add a parser for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
It has become more common to use config fragments to extend or adjust
the functionality of boards in U-Boot.
Add some documentation for how to use this with buildman.
Signed-off-by: Simon Glass <sjg@chromium.org>
Check that configuration fragments provided to buildman as comma-
separated list are passed on to the make command of the builder.
In the %_defconfig: target of scripts/kconfig/Makefile the defconfig
file and the fragments are combined via the gcc preprocessor.
Modeling this step in the buildman testbench without invoking the actual
Makefile would not provide better test coverage.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Currently we are no able to build with configuration fragments in our CI.
With this patch buildman gets a new argument --fragments for passing a
comma-separated list of configuration fragments to add to the board
defconfigs, e.g.
tools/buildman/buildman \
-o build \
-k qemu-riscv64_smode \
--fragments acpi.config
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This option doesn't work as expected since it sets the cwd to the work
directory, which does not necessarily hold the source code.
It should be left unset, so that the current directory is the source
directory.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: #3
This function is sometimes useful outside tests. Also it can affect how
terminal output is done, e.g. whether ANSI characters should be emitted
or not.
Move it out of the test_util package and into terminal.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
With the switch to using GCC 14.2.0 in commit 001bac5f16 ("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>
Use the "pipreqs" tool to re-create these files, with a few manual
corrections. We still need to include pytest-xdist which the tool does
not detect. We also for now don't upgrade most of the required tools as
that creates problems with various tests, which should be resolved
independently.
Signed-off-by: Tom Rini <trini@konsulko.com>
Recent versions of this module call time.perf_counter() so add a patch
for this also.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tom Rini <trini@konsulko.com>
This newer pylint produces errors about variables possibly being used
before being set. Adjust the code to pass these checks.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tom Rini <trini@konsulko.com>
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>
At present buildman only supports building the default target. Generally
this is what is wanted, but in some cases boards erroneously have a
different target for product extra files.
Add a --target option to help. Also add a comment indicating which
letters are free for new options.
Signed-off-by: Simon Glass <sjg@chromium.org>
Buildman has always treated the lack of a toolchain as an infrastructure
problem rather than a build failure.
However the logic for this is not correct, since it does not write a
'done' file in this case.
As a result, one of two things can happen.
1. If a previous build ran in the same (output) directory, the outcome
of *that* build is recorded as the outcome of this one
2. Otherwise, no outcome is recorded
Obviously this inconsistency is not ideal. While (2) is rare, it can be
very confusing as the build sort-of fails but does not produce any
summary output with 'buildman -s'
Overall it seems better to attribute a toolchain issue to the boards
that it affects. This results in clear failures which can be examined,
no matter what happened in the .bm-work directory previously.
So write a 'done' file for each build when a toolchain is missing.
The end result of this patch is to make missing toolchains much more
obvious. It should be things a bit easier for novice users.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is not actually used but its presence suggests that it is the
filename for the board database. Drop it to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is used by some boards in U-Boot and is a convenient way to deal
with common settings where using a Kconfig files is not desirable.
Detect #include files and process them as if they were part of the
original file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/30
This code is tested by test_scan_defconfigs() but it is useful to have
some specific tests for the KconfigScanner's operation in U-Boot. Add
a test which checks that the values are obtained correctly.
Signed-off-by: Simon Glass <sjg@chromium.org>
For most boards, the device-tree compiler is built in-tree, ignoring the
system version. Add a special option to skip this build. This can be
useful when the system dtc is up-to-date, as it speeds up the build.
Signed-off-by: Simon Glass <sjg@chromium.org>
Buildman retries a failed build when processing a branch, but does not
do this when building current source. It is useful to do this retry in
both cases, so add the logic for it.
Signed-off-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>
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 Linux kernel documentation has transitioned from using
kconfig-language.txt to kconfig-language.rst. Therefore update all
occurrences of kconfig-language.txt.
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
