Fixed the build on Debian/kfreebsd
Fix mingw based builds. Fixes #587
Merge pull request #588 from jonforums/mingw-fix

Fix mingw based builds. Fixes #587
Merge pull request #586 from grimmy/master

Build fails on Debian/kfreebsd
Stop `-t msvc -o` from lowercasing paths from /showIncludes output.

/showIncludes prints absolute paths. If a source file says
`#include <WiNdOwS.h>`, /showIncludes will use that spelling in
its output for the basename and use the on-disk cache for the
directory names in the rest for its output.

This makes the .d files created by `-t msvc -o` consistent with the
.d files written by gcc and clang.
Before this change, `-t msvc -o` would convert this output to
lower case. This is a problem if a build step produces a header file
with mixed case, such as "RuntimeFeatures.h". Due to the lowercasing,
the .d file would contain "runtimefeatures.h", while the build step
will create "RuntimeFeatures.h". Due to the case difference, ninja
would not realize that regeneration of the .h file would require
a rebuild of all source files having the header in the .d file.
(On the next build, ninja would rebuild them since stat()ing is not
case-sensitive on Windows.) One possible fix for this is to make sure
that generators always write generated header files in lower case too,
but on Mac gcc doesn't do lower-casing and .d files end up with the
case-as-written, so generators would have to be different on Mac and
Windows, which is undesirable.

If case-insensitve path comparisons are useful, they should be done
somewhere else (e.g. in CanonicalizePath()) where they affect both
paths read from .d files and paths read from .ninja files. This should
then be controlled by a top-level variable.

This patch changes behavior, but it only has an effect on generated
header files, which aren't common, and it only affects -t msvc, which
is still marked as experimental. (cmake doesn't use it yet.)

(If a file has both `#include <windows.h>` and `<Windows.h>`, this
will now take 2 stat() calls instead of just one, but that should
have a negligible cost.)
Merge pull request #589 from nico/wincase

Stop `-t msvc -o` from lowercasing paths from /showIncludes output.
Fix restat builds with edges generating headers depended on through deps files
in deps mode.

`ImplicitDepLoader::LoadDepFile()` already adds a depfile edge from every file
mentioned in a depfile to the depfile's output.

`ImplicitDepLoader::LoadDepsFromLog()` didn't do this yet, so add it. Else,
if a restat rule clears a generated .h file, this wouldn't propagate to cc files
depending on that .h file through a depfile.

Fixues issue #590.
Merge pull request #591 from nico/fixrestat

Fix restat builds with edges generating headers depended on through deps...
Add test that proves `node->AddOutEdge(edge);` in `LoadDepFile()` is needed.

No functionality change. Related to issue #590.
Merge pull request #592 from nico/addtest

Add test that proves `node->AddOutEdge(edge);` in `LoadDepFile()` is nee...
Add a test for CreatePhonyInEdge() in depsmode path.

Removing the `CreatePhonyInEdge(node);` line in
`ImplicitDepLoader::LoadDepsFromLog()` made no tests fail before this change.
The new test is a port to depsmode of the existing DepFileOK test.
Merge pull request #593 from nico/moretest

Add a test for CreatePhonyInEdge() in depsmode path.
Make sure to not write partial deps entries.

When two ninja instances run in parallel in the same build directory,
one instance could write a deps entry header and a few ids, and then the
other instance could write a file name in the middle of the deps header.
When ninja reads this deps log on the next run, it will deserialize the
file name as indices, which will cause an out-of-bounds read.

(This can happen if a user runs a "compile this file" that uses ninja to
compile the current buffer in an editor, and also does a full build in a
terminal at the same time for example.)

While running two ninja instances in parallel in the same build
directory isn't a good idea, it happens to mostly work in non-deps mode:
There's redundant edge execution, but nothing crashes. This is partially
because the command log is line-buffered and a single log entry only
consists of a single line.

This change makes sure that deps entries are always written in one go,
like command log entries currently are. Running two ninja binaries in
parallel on the same build directory still isn't a great idea, but it's
less likely to lead to crashes.

See issue #595.
Merge pull request #596 from nico/chunk

Make sure to not write partial deps entries.
Add stdlib.h include for atol().

This attempts to fix issue #600. `man atol` claims that atol() is in
stdlib.h, which wasn't included yet.
Merge pull request #601 from nico/109fix

Add stdlib.h include for atol().
support Bitrig
cleanup based on comments from martine
ugh, missing #
Exclude Windows as well