Re: GNU make 3.81beta4 released

[Paul D. Smith]

%% Eli Zaretskii <address@hidden> writes:

  ez> update_file should launch at most 1 command.  Am I missing something?

I'd have to check to be sure, but IIRC update_file() does everything
necessary to update that particular target.  It works recursively, so
that could mean updating lots of prerequisites as well, and the number
of commands run could well be >1.

  ez> I think there should be a way for remake.c to know in advance that
  ez> no more processes can be safely launched.  When that happens, it
  ez> should not even try to launch more commands, but instead queue
  ez> them for later.

That's not really how make's algorithm works.  I think changing it would
be a major structural change.  All the information about number of jobs,
etc. is contained in job.c.  When remake.c finds a new job to start, it
will call into job.c.  If there are enough resources to start it, then
job.c will do so and return, and remake.c starts looking for another job
to start.

If not, job.c waits around until it can start one, then returns.

  ez> As I wrote here yesterday, I think a similar problem exists on
  ez> Posix platforms, albeit for slightly different reasons (the limit
  ez> imposed by the OS on the number of processes).  If Paul agrees
  ez> that this is a bug, then perhaps we could have a
  ez> system-independent solution for it that will incorporate the
  ez> Windows idiosyncrasies.  If not, I will craft something
  ez> Windows-specific.

If make behaves badly (crashes or gives bizarre-o errors) then it's a
bug.  I only skimmed your message yesterday so I haven't thought
carefully about it yet.  But, it probably deserves a bug report in
Savannah.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist