Re: GNU make 3.81beta4 released

[Paul D. Smith]

%% Eli Zaretskii <address@hidden> writes:

  ez> If this is so, then relying on that number to fit into a 8-bit field
  ez> of (struct dep *)->changed is playing with fire, IMHO.

Definitely.

  ez> Unless you agree that we should modify this:

  ez> g->changed += commands_started - ocommands_started;

  ez> into this:

  ez> g->changed = commands_started > ocommands_started;

I haven't checked where "changed" is used but as long as it's always
only treated as a boolean value and never as a count that change should
be made.

If it ever IS treated as a count then obviously we have more work to do
to fix the problem... maybe just making this a 32-bit value instead.

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

Not sure what you mean by "close to the current limit"... how would make
know that?

At least on POSIX, it's pretty dynamic where the limit is.

  >> If make behaves badly (crashes or gives bizarre-o errors) then it's a
  >> bug.

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

EAGAIN?  Really?   Hm.  Looks like you're right.  Make _should_ handle
this more gracefully, perhaps by waiting (and ENOMEM as well).

The problem is there's nothing for make to wait _FOR_; it would just
have to sleep and then try again... and that has to be worked into
make's current wait algorithms which are already too complicated.  This
is a good fix to make for robustness' sake, but it'll involve some
not-insignificant surgery in job.c I think.

Please report it on Savannah so we don't lose track.

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