On Wed, 2017-05-31 at 19:48 -0400, Paul Smith wrote: > I'm working on ensuring that the test suite works on Windows (some of > that means disabling tests until someone has a chance to rework them to > be more portable, unfortunately :-/).
I've pushed these changes. Note that the test suite is not passing 100% on Windows; there are 5 tests that fail (and a number that are skipped, but that's to be expected). I think at least one of the failures is a real bug (in targets/POSIX if we set .SHELLFLAGS and there's whitespace in the path to sh.exe, which there is on my system, something weird happens). One test in features/jobserver fails and I don't understand why. This may or may not be a real bug. The other three failures I believe are due to test suite issues with CRLF but I haven't dug into them. I have another change which is attempting a code cleanup for output sync, and then a change beyond that which is a cleanup for lots of Windows warnings. However, the output sync cleanup causes the output_sync test to hang on Windows (that is what started me down this path of cleaning up the test suite for Windows) so I think I broke something; I need to fix that before pushing. Hopefully it was a silly think-o that won't be hard to fix. Once I get this working I need to make some changes to output sync on POSIX systems because some systems (e.g., MacOS (and FreeBSD?)... boo!) don't allow locks to be set on TTY device file descriptors :-/. I need to sit down with some paper or a whiteboard and understand the ramifications of using a separate FD as the output sync lock device. The great thing about using stdout is that if someone redirects it then you magically avoid any locking on that job. Maybe we'll just have to settle for diminished capabilities on systems where you can't lock a TTY FD. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
