New push (was: Re: Q: On Windows why not ignore CRLF?)

[Paul Smith]

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.