[U-Boot] MAKEALL
Simon Glass
sjg at chromium.org
Sun Feb 16 05:57:15 CET 2014
Hi,
On 12 February 2014 03:42, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> Hi Albert,
>
>
>> > It might also be worth looking at tools/buildman, which automatically
>> > allocates one build thread per CPU.
>>
>> Jumping in late, but my question is incidental and not urgent anyway.
>>
>> Would using buildman make the multiple build / multiple CPU code in
>> MAKEALL useless? I'm wondering whether we could apply the Unix
>> philosophy here (1), let buildman alone deal with handling parallel
>> builds, and remove code from MAKEALL.
>
This is a good summary thank you, but I have a few comments as well.
> I think parallel build feature is missing from buildman.
> So, buildman cannot check if -j option is working correctly.
It is not used by default, but there is a -j option. If you use -j,
first make sure you reduce the number of threads to compensate. So for
example you can use:
buildman -j 8 -T 1
to use -j8 with only a single thread on a 8-core machine. I typically
find that building with -j1 and increasing the thread count is much
faster. Another tip if you are not using your machine for anything
else is to use -T with a number 20-30% larger than the number of CPUs
you have.
>
> Note:
> Please do not be confused by the difference of
> what "parallel" means.
>
> [1] MAKEALL runs single "make" thread by default.
> (You can change this with BUILD_NBUILDS variable)
> One "make" thread runs multiple jobs by giving -j option.
> (You can change this with BUILD_NCPUS variable)
>
> [2] buildman runs multiple "make" threads.
> Each make thread runs one job (that is, always -j 1 ).
>
Indeed, this is the default behaviour, but it can be changed with options.
>
>
> Besides parallel build , I notice some differences between MAKEALL and
> buildman.
>
> - MAKEALL runs "make mrproper" everty time before "make",
> but buildman doesn't.
> This means objects are remaining, that were generated
> by the previous commit.
> So, even if some build rules in makefiles get broken at an
> intermediate commit, buildman possibly cannot detect the error.
That is correct. To get the MAKEALL behaviour you need to give the -f option.
>
> - MAKEALL can select in-tree-build or out-of-tree build
> by BUILD_DIR option, but buildman always does out-of-tree build.
That's right, in fact buildman does not support in-tree build at all
unfortunately. However, given that every thread has its own git tree,
it would actually be fairly easy to add this feature.
>
> (Simon, please correct me if I am wrong.)
>
> If you touch only C sources, buildman is enough (and faster).
>
> But if you change make targets, it is highly recommended
> to check with MAKEALL.
> At least, I need both. (for Kbuild and Kconfig work)
>
> I guess we cannot replace MAKEALL with buildman for now.
The intent was that buildman supported everything that MAKEALL does
and more. I believe that is true except for the in-tree build you
mention above. However, I think there might also be some small
difference between the way the -f option is implemented in buildman,
and the way MAKEALL works. It might be worth splitting the -f option
into two:
- one to force rebuild of a board
- another to force a reconfigure on every build
Then we could be sure. In summary, if we do that and support in-tree
builds then I think buildman has all the features of MAKEALL.
BTW a few other options that buildman has, which people may not have noticed:
-S - shows increase/decrease of image sizes across commits
-B - same but for individual functions
-k - keep the build outputs
-d - show detailed board information
-S - allows building every second commit, or only first and last, etc.
Regards,
Simon
More information about the U-Boot
mailing list