A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1436 
====================================================================== 
Reported By:                steffen
Assigned To:                
====================================================================== 
Project:                    1003.1(2016/18)/Issue7+TC2
Issue ID:                   1436
Category:                   Shell and Utilities
Type:                       Enhancement Request
Severity:                   Editorial
Priority:                   normal
Status:                     Resolved
Name:                       steffen 
Organization:                
User Reference:              
Section:                    Vol. 3: Shell and Utilities, Issue 7, make 
Page Number:                2969 
Line Number:                98473 
Interp Status:              --- 
Final Accepted Text:        https://austingroupbugs.net/view.php?id=1436#c5327 
Resolution:                 Accepted As Marked
Fixed in Version:           
====================================================================== 
Date Submitted:             2020-12-15 21:00 UTC
Last Modified:              2021-04-23 17:47 UTC
====================================================================== 
Summary:                    make: add "-j max_jobs" option to support
simultaneous rule processing
====================================================================== 

---------------------------------------------------------------------- 
 (0005330) psmith (developer) - 2021-04-23 17:47
 https://austingroupbugs.net/view.php?id=1436#c5330 
---------------------------------------------------------------------- 
> shall between them update no more than maxjobs targets in parallel

It's not clear from the text whether this set of targets includes make
itself.  In a recursive make scenario, you will be running sub-makes to
create targets.   In GNU make we do not count make itself as one of the
targets to be updated and I recommend this behavior here as well.

If you don't have this, then you can have a situation where you run with
-jN and you invoke N instances of sub-makes, and now no sub-make can start
a new target because all available jobs are used.

Not counting make is sensible because while all jobs are running, make
itself is not actually running: it's waiting for one of the jobs to
complete. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2020-12-15 21:00 steffen        New Issue                                    
2020-12-15 21:00 steffen        Name                      => steffen         
2020-12-15 21:00 steffen        Section                   => Vol. 3: Shell and
Utilities, Issue 7, make
2020-12-15 21:00 steffen        Page Number               => 2969            
2020-12-15 21:00 steffen        Line Number               => 98473           
2021-03-22 21:27 psmith         Note Added: 0005299                          
2021-04-22 15:34 rhansen        Note Added: 0005327                          
2021-04-22 15:36 rhansen        Interp Status             => ---             
2021-04-22 15:36 rhansen        Final Accepted Text       =>
https://austingroupbugs.net/view.php?id=1436#c5327    
2021-04-22 15:36 rhansen        Status                   New => Resolved     
2021-04-22 15:36 rhansen        Resolution               Open => Accepted As
Marked
2021-04-22 15:36 rhansen        Tag Attached: issue8                         
2021-04-22 18:36 psmith         Note Added: 0005328                          
2021-04-23 17:40 psmith         Note Added: 0005329                          
2021-04-23 17:47 psmith         Note Added: 0005330                          
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
      • Re:... Paul Smith via austin-group-l at The Open Group
        • ... Nick Stoughton via austin-group-l at The Open Group
          • ... Paul Smith via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to