%% Eli Zaretskii <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
