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
