On 05/04/2016 12:58 PM, Tom Rini wrote:
On Wed, May 04, 2016 at 12:55:15PM -0600, Stephen Warren wrote:
On 04/11/2016 10:48 AM, Stephen Warren wrote:
From: Stephen Warren <swar...@nvidia.com>
One use-case for buildman is to continually run it interactively after
each small step in a large refactoring operation. This gives more
immediate feedback than making a number of commits and then going back and
testing them. For this to work well, buildman needs to be extremely fast.
At present, a couple issues prevent it being as fast as it could be:
1) Each time buildman runs "make %_defconfig", it runs "make mrproper"
first. This throws away all previous build results, requiring a
from-scratch build. Optionally avoiding this would speed up the build, at
the cost of potentially causing or missing some build issues.
2) A build tree is created per thread rather than per board. When a thread
switches between building different boards, this often causes many files
to be rebuilt due to changing config options. Using a separate build tree
for each board would avoid this. This does put more strain on the system's
disk cache, but it is worth it on my system at least.
This commit adds two command-line options to implement the changes
described above; -I ("--incremental") turns of "make mrproper" and -P
("--per-board-out-dir") creats a build directory per board rather than per
thread.
Tested:
./tools/buildman/buildman.py tegra
./tools/buildman/buildman.py -I -P tegra
./tools/buildman/buildman.py -b tegra_dev tegra
./tools/buildman/buildman.py -b tegra_dev -I -P tegra
... each once after deleting the buildman result/work directory, and once
"incrementally" after a previous identical invocation.
Signed-off-by: Stephen Warren <swar...@nvidia.com>
Reviewed-by: Tom Rini <tr...@konsulko.com>
Acked-by: Simon Glass <s...@chromium.org> # v1
Tested-by: Simon Glass <s...@chromium.org> # v1
Tom, it's been over 3 weeks since I posted this, and Simon ack'd v2.
Well, the release is next week. Simon didn't include it in a PR since
v2 was posted so I assume he was figuring on waiting until next release
for it. Does this really need to come in before the release or can it
wait?
I suppose it isn't critical to the functionality of the release, so from
that perspective it can wait.
I will point out that the patch was first posted over 5 weeks ago,
within the merge window, and the only revision was the addition of some
README text, so I'd be disappointed if it took another 3 weeks to get
applied.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
