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

[Simon Glass <sjg@chromium.org>]

Hi Tom,

On 4 May 2016 at 13:09, Stephen Warren <swarren@wwwdotorg.org> wrote:
> 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@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@nvidia.com>
>>>> Reviewed-by: Tom Rini <trini@konsulko.com>
>>>> Acked-by: Simon Glass <sjg@chromium.org> # v1
>>>> Tested-by: Simon Glass <sjg@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?

No I was just expecting you to pick it up as it is in your queue :-)

>
>
> 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.

Regards,
Simon