On Fri, 2013-08-16 at 22:52 +0400, Pavel Fedin wrote:
> > Exactly, hence the reason for my question.  I'm not interested in adding
> > this if, when it's enabled, things don't work correctly.
> 
> > On the other hand I'm not sure it's not possible to get things working
> > correctly.  Or, perhaps it's possible to make them work correctly
> 
>  Let me come in again ? Let's  take  a  look at what we have. We have
> a pending change, which has undergone some testing. It works.  At  the
> other  hand, there can be some corner cases. May be let's be
> constructive and test them, instead of just speculating about what can
> happen  and  what  cannot ?

Testing is very useful to be sure.  However, the complexity of make is
such that I suspect it will be EASIER, faster, and probably more
accurate, to look at the (limited amount of) code in question than to
try to test all the possible corner cases.  Even the current make
regression suite, at over 500 individual tests, is a very far cry from
complete.

> A  small analogy: you can speculate that tomorrow,  when  you  come
> out of your home, a brick can fell from the roof  and  kill  you.  Now
> what ? Don't ever come out of house ? Wear builder's helmet ? :)

If someone is replacing my chimney I'd definitely look up whenever I
came out of my house, and watch for falling debris.  I'd also ask them
to think about what precautions to take so as not to drop things on me.

>  To  me  current  situation  looks non-constructive. You say: "Current
> implementation   works,  new  implementation  theoretically  may  fail
> (because   it's   new),   so   we   must  not  change the code".

That, though, is not what I said.  What I asked for, perhaps not clearly
enough, was for someone to investigate the current operations that make
performs in the child between the fork and exec calls (of which there
not so many) and decide, for each one, whether (a) it has no purpose in
a Cygwin environment, or (b) it's not needed when using spawn(), or (c)
it is needed but there's a reasonable way to get the same behavior with
spawn(), or (d) it can't be duplicated, but it's only needed for some
optional feature of GNU make (e.g., output sync) which can be disabled
when spawn() is set up, or (e) it's needed and there's no mitigation.

And for anything in category (e), it would be good if we can understand
what the lost/incorrect functionality looks like.

Oh and this should be done on the current HEAD of the Git master branch,
or at least the current RC1 release, not on the code in GNU make 3.82.

That would be a productive, and probably quite interesting, conversation
that would move us in a positive direction, rather than spinning our
wheels as we seem to be currently.  After all, there are reasons to
consider using spawn-like calls on UNIX systems, where available, as
well.  Maybe this could enlighten us as to what might be possible.  I'm
quite happy to discuss or explain the code, if necessary.


_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Reply via email to