> Date: Fri, 16 Aug 2013 22:52:55 +0400 > From: Pavel Fedin <pavel_fe...@mail.ru> > Cc: Christopher Faylor <cgf-please-use-the-mailingl...@gnu.org>, > bug-make@gnu.org > > 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". Is it > correct developer's approach ? Yes, changes sometimes introduce bugs, > that's OK. Doesn't this mean that we just need to add some tests ? > Can anyone (opponents) give ideas on what exactly needs to be > tested ? I can extend make's test suite then.
You are missing the point. The problem with this change is not that it changes code. The problem is that it replaces the fork/exec paradigm, which implements a well-known set of requirements, with a call to 'spawn', whose requirements are different and much less known (because it is not covered by any standard). Moreover, while fork/exec have the same functionality in Cygwin as they have on other Posix platforms, 'spawn' has no equivalents on Posix platforms, and the mainstream Make developers know nothing about it. Since Cygwin users expect Cygwin programs, Make included, to behave exactly like they do on Posix platforms, introducing an interface that is not used on Posix will cause a divergence between the Cygwin behavior and the Posix behavior of GNU Make. Please re-read again what Paul wrote: the code in GNU Make between the call to 'fork' and the subsequent call to 'exec' is the source of concern here. Even if you prove by inspection of the current code of 'spawn' in Cygwin's library that the same code runs in 'spawn', any future changes in GNU Make between these two calls, or any changes in the implementation of 'spawn', will invalidate that proof. IOW, even if today the two versions are exactly identical (and I'm not sure they are), they can become different at any time in the future, without any notice. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
