Re: [Buildroot] [PATCH 1/1] package/libnss: fix parallel build failure

[Arnout Vandecappelle <arnout@mind.be>]

On 19/10/2021 19:59, Giulio Benetti wrote:
> Or…
> 
>> Il giorno 19 ott 2021, alle ore 19:40, Giulio Benetti 
>> <giulio.benetti@benettiengineering.com> ha scritto:
>>
>> Hi Arnout,
>>
>>> Il giorno 6 ott 2021, alle ore 21:20, Arnout Vandecappelle <arnout@mind.be> 
>>> ha scritto:
>>>
>>> 
>>>
>>> On 22/09/2021 01:59, Giulio Benetti wrote:

[snip]
>>>> ++.NOTPARALLEL: $(1)
>>>
>>> This doesn't make a whole lot of sense: .NOTPARALLEL is something that 
>>> applies to the Makefile as a whole, not to one specific target. I haven't 
>>> looked in any depth in the libnss build system, but unless it builds 
>>> recursively, adding this is exactly equivalent to adding
>>>
>>> .NOTPARALLEL:
>>
>> As I’ve tested it’s not like this.
>>
>> I read this from [1]:
>> ‘’’
>> |.NOTPARALLEL|
>>
>>     If |.NOTPARALLEL| is mentioned as a target, then this invocation of
>>     |make| will be run serially, even if the ‘-j’ option is given. Any
>>     recursively invoked |make| command will still run recipes in parallel
>>     (unless its makefile also contains this target). Any prerequisites on this
>>     target are ignored.
>>
>> ‘’’
>>
>> They talk about target and it is what I experience.
>> It’s a bit ambiguous honestly. 

"target" is the thing on the left-hand side of a colon. So in

.NOTPARALLEL: %.bmp

the target is .NOTPARALLEL. My point is that the thing on the right-hand side of 
the colon is ignored. It makes no difference at all if you put %.bmp there, or 
blablabla - when you use that Makefile, the -j option will be ignored.

So what you're doing is that you make the whole thing not run in parallel, not 
just the build of whatever you put on the right-hand side.


>> In the past I’ve also
>> experienced it on a big Makefile where I had .bmp files to be converted with 
>> xxd and that gave parallel problems. So I’ve tagged it like:
>>
>> .NOTPARALLEL: %.bmp
>>
>> and that solved the problem.
> 
> …it is because in both cases they are called recursively.

  Because it is called recursively, the higher-level make invocations are indeed 
still run in parallel.

  Therefore, indeed, it does make sense to put it inside the macro.

  But it doesn't make sense to add a right-hand side.

  Anyway, since it's been applied upstream, we can just ignore the issue.

  Regards,
  Arnout


> 
> Giulio
> 
>>
>> Also they have just upstreamed the patch [2], so
>> we can test if it works committing this patch or
>> by bumping next version.
>>
>> Then it’s up to you :-)
>>
>> Best regards
>> Giulio Benetti
>> Benetti Engineering sas
>>
>> [1]: https://www.gnu.org/software/make/manual/html_node/Special-Targets.html 
>> <https://www.gnu.org/software/make/manual/html_node/Special-Targets.html>
>> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1731911 
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1731911>
>>
>>>
>>> anywhere in the Makefiles. This is BTW what we do in Buildroot.
>>>
>>> And in the end, that's the same as calling $(MAKE1) from Buildroot, so 
>>> patching is not really needed.
>>>
>>> If you want to be a little smarter, you will have to manually "unroll" the 
>>> dependency, like:
>>>
>>> $(1): | $(3)/d
>>>    $$(foreach tgt,$(2),$(MAKE) $(3)/$$($(tgt)))
>>>
>>> (chances are I made some major mistake in this thing).
>>>
>>> Or if it does build recursively, you can probably conditionally add 
>>> .NOTPARALLEL in some smart way.
>>>
>>> Anyway, I've marked this patch as Changed Requested.
>>>
>>> Regards,
>>> Arnout
>>>
>>>
>>>> + endif
>>>> + else
>>>> + $(1):
>>>> +--
>>>> +2.25.1
>>>> +
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot