Re: [Buildroot] [PATCH] linux/linux.mk: forcibly (re)enable Make jobserver

On 30/07/2026 22:18, Laszlo Ersek wrote:
> On 7/30/26 20:14, Arnout Vandecappelle wrote:
>>
>>
>> On 30/07/2026 20:06, Laszlo Ersek wrote:
>>> Commit 0b9efc991f8a («linux: use BR2_MAKE», 2023-04-10) replaced
>>> $(MAKE) with $(BR2_MAKE) in a number of recipes. As a consequence,
>>> the child make is unable to discover the job server, and we get a
>>> warning such as
>>>
>>>> warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
>>>
>>> https://www.gnu.org/software/make/manual/html_node/Error-Messages.html
>>> https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html
>>>
>>> Inform the parent Make, by prefixing the recipe with "+", that
>>> $(BR2_MAKE) can deal with the job server.
>>>
>>> Cc: Arnout Vandecappelle <[email protected]>
>>> Cc: Oleg Lyovin <[email protected]>
>>> Cc: [email protected]
>>> Signed-off-by: Laszlo Ersek <[email protected]>
>>> ---
>>>
>>> Notes:
>>>      Commit 0b9efc991f8a replaces multiple instances of $(MAKE) with
>>>      $(BR2_MAKE); I'm only prefixing the one recipe with "+" that
>>>      seems to cause the most noticeable slowdown for me (by missing
>>>      out on a parallel kernel build).
>>
>>   Are you really sure this speeds things up?
> 
> Yes.

  Ah, I just saw now that _BUILD_CMDS already has a + in pkg-generic.mk.


>> The core of the work should be in the `make all` invocation on line
>> 546. All the other invocations should be pretty much serial. In
>> particular the rebuild-with-initramfs should do nothing more than
>> re-linking and re-compressing the kernel because the exact same
>> command was already done in the build step.
> 
> In my case,
> 
> - both "LINUX_BUILD_CMDS" -- the "all" target --,
> 
> - and "linux-rebuild-with-initramfs" -- the $(LINUX_TARGET_NAME), aka
>    "Image" target --
> 
> seem to perform a similarly large [1] kernel build. The first one builds
> object files concurrently already, the second one (without this patch)
> doesn't.
> 
> [1] The "Image" build (from "linux-rebuild-with-initramfs") seems not to
> execute the following types of recipes from the "all" target (from
> "LINUX_BUILD_CMDS"):
> 
> - CC [M]
> - LD [M]
> - CHKSHA1 on various headers
> - COPY on various headers
> - DTC on various device tree files
> - GZIP on Image.gz
> - UPD and WRAP on various generated header files
> 
> I think these differences are expected. However, while
> "linux-rebuild-with-initramfs" performs fewer build steps, according to
> the above, it does build all the built-in object files anew, and that

  That's weird though. Well, it's not weird that it doesn't re-do the modules 
because the LINUX_TARGET_NAME goal doesn't build the modules. But it's weird 
that it rebuilds the builtin object files, nothing should have changed compared 
to the earlier run except for the single object file that contains the initramfs 
cpio image.

  It would be nice to fix that, but regardless, it's not a bad idea to add the + 
to the rebuild-with-initramfs goal so I'll apply this patch.

  Regards,
  Arnout


> happens way more slowly than in "LINUX_BUILD_CMDS", because
> "linux-rebuild-with-initramfs" doesn't do it concurrently.
> 
> (FWIW, I'm based off of release 2025.05.)
> 
> Laszlo

_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot