Quentin Garnier wrote:

>On Fri, Aug 18, 2006 at 05:19:02PM +0200, Martin Husemann wrote:
>  
>
>>On Fri, Aug 18, 2006 at 04:37:54PM +0200, Quentin Garnier wrote:
>>    
>>
>>>But how is it supposed to go to a child instance of make, then?
>>>I don't claim to understand anything about make, let alone its inner
>>>workings :)
>>>      
>>>
>>By make adding it (silently) to the args (but not publishing that through
>>MAKEFLAGS) when creating a child make process, if it has been invoked with -j
>>or -J itself.
>>
>>If make invokes a shell script, and that invokes another make, it is IMHO
>>not part of the recursive/parallel make tree - so the token queue should not
>>be passed on to it.
>>    
>>
>
>Somehow it makes me think a lot of magic will be required for make to
>know it's invoking make--and moreover, the correct one.  Also, I think
>that the current scheme allow other make programs to co-operate,
>although it might not be an intended feature.
>
>  
>
I don't think we are on the right track here.
One thing that puzzles me is that make apparently complains
about childs it does not know about. My understanding of Unix
principles is that SIGCLD and/or the wait-results is either
delivered to the immediate parent or init in case a process is orphaned.
That means make must have forked the childs it claims to know nothing
about. I cannot see how a sub-make(/process) could fork processes where the
grand parent gets to see the exit codes via wait(pid)(). Where did I miss
something here ? I still have the impression that the job list handling may
be incomplete (unless, of course, make has pid 1 :-)). It may be that the
forks happen at a(nother) place (e.g. library) where they are not 
entered in the job
list. If that is the case (and can be proven), then we should get rid of 
the message
as it is of limited (and confusing) value if we are not able by design 
to catch all
forked pids in the job list. If the joblist is definitely complete, we 
have a coordination
issue.

Frank