[CMake] ninja under windows

[James Johnston]

> -----Original Message-----
> From: CMake [mailto:cmake-bounces at cmake.org] On Behalf Of Gonzalo
> Garramuño
> Sent: Monday, August 03, 2015 17:23
> To: cmake at cmake.org
> Subject: [CMake] ninja under windows
> 
> I compiled Ninja on cygwin from git.  That now works fine it seems.
> I am trying to compile for msvc.  However, when cmake runs, I get:
> 

I wouldn't even go there...  I would recommend:

 * Do not build anything requiring native Windows build tools from Cygwin -
for example, don't call Visual C++ compiler from Cygwin.

 * Consider not build anything requiring native Windows build tools from
MSYS/MSYS2, like Visual C++ compiler, since MSYS/MSYS2 is a fork of Cygwin.
(Unless MSYS/MSYS2 maintainers patch Cygwin to resolve the problems, which
you'd better research before going there.)

It sounds drastic but I can tell you from experience that eventually you'll
run into problems and you may be on your own.  The big reason I have run
into is that Cygwin's handling of stdin/out/err pipes differs from how most
Windows programs (i.e. programs based on Visual C++ runtime, or based on
.NET Framework) handle the pipes.  They do this for POSIX compatibility
reasons, I'd guess.  And the Cygwin maintainers in the past have shown
limited interest in being compatible with non-Cygwin programs.
	
The end result is you end up with things like a basic/simple .NET Framework
4.0 program not working right if called from Cygwin, for example.

If you want to forge ahead, I can offer two suggestions that seem to
mitigate the problems - today anyway: 

* Set CYGWIN environment variable to contain pipe_byte.  This is very
important but I forget the specifics why, other than non-Cygwin programs
break if this isn't set.  (Search the Cygwin mailing lists for my posts on
the issue).

* Make a custom build of Cygwin and then set CYGWIN environment variable to
contain pipe_nooverlap (a flag I added).  This is also very important
because if you don't, .NET Framework 4.0 apps and potentially other programs
called from Cygwin will break.  I submitted a patch to Cygwin maintainers
but they rejected it, so you'll have to build Cygwin yourself (and rebuild
it every time the maintainers release new Cygwin version).  The link to the
patch is here:
https://cygwin.com/ml/cygwin-patches/2013-q4/msg00020/pipepatch

Setting these flags maybe breaks some POSIX compatibility but in practice, I
have had zero problems with common Cygwin programs (bash, coreutils). 

Since proper interaction with non-Cygwin programs now requires you to make a
custom build of Cygwin - a big hassle - I suggest don't even go there, and
keep Cygwin (and its MSYS/MSYS2) derivatives out of your build system if you
require calling native Windows apps (e.g. Visual C++).

There are other unrelated considerations if you want a 100% solid build
environment, like you should research the (non-)reliability of forking under
Cygwin/MSYS/MSYS2.  I have to commend the Cygwin developers for making it
work in the first place, since Windows provides no forking API.  But in the
end, to get POSIX working on the Win32 API, I think they are relying on a
lot of undocumented Win32 stuff that works in practice but subject to
breakage when new versions of Windows come out, etc.

> 
> Is compiling under the microsoft compiler not an option for ninja files (
I can
> compile with NMake Makefiles just fine in the same project ).

It is and we do it, here is how:

1.  Don't build Ninja under Cygwin.  IIRC the procedure would be (a) install
Python for Windows, (b) go to a Visual C++ command prompt to set up VC++
environment, (c) call Ninja bootstrapper script.

2.  Run CMake from a Visual C++ command prompt when you want to use the
Ninja generator because Ninja generator will just look for whatever "cl.exe"
is in the PATH.

At no point does Cygwin enter into the equation.

Best regards,

James Johnston