make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU make 3.81beta4 released


From: Eli Zaretskii
Subject: Re: GNU make 3.81beta4 released
Date: Fri, 20 Jan 2006 20:36:23 +0200

> Date: Fri, 20 Jan 2006 12:40:50 -0500
> Cc: "Markus Mauhart" <address@hidden>, address@hidden
> From: "Paul D. Smith" <address@hidden>
> 
> %% 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.

If this is so, then relying on that number to fit into a 8-bit field
of (struct dep *)->changed is playing with fire, IMHO.  Unless you
agree that we should modify this:

      g->changed += commands_started - ocommands_started;

into this:

      g->changed = commands_started > ocommands_started;

>   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.

Sorry, you are right.  What I really meant was that load_too_high
(which is indeed in job.c) should check whether the number of jobs is
close to the current limit, and if so, it should return non-zero.

>   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.

What happens is that the rule's commands fail because vfork fails with
EAGAIN.  So the target is not remade.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]