[U-Boot] [PATCH V2] buildman: allow more incremental building

[Stephen Warren]

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 <swarren at 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 <swarren at nvidia.com>
>>> Reviewed-by: Tom Rini <trini at konsulko.com>
>>> Acked-by: Simon Glass <sjg at chromium.org> # v1
>>> Tested-by: Simon Glass <sjg at 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.