[CMake] Building ninja with the MinGW compiler on Wine

[Alan W. Irwin]

I am interested in using the ninja build tool to speed up software
builds on the Wine version of Windows so the first step in that
process was to build ninja itself.  That turned out to be a bit of an
adventure until I discovered the changes required to achieve success.
So I am detailing my
notes here in case anybody else runs into similar trouble
with building ninja with the MinGW compiler on either the
Wine or Microsoft versions of the Windows platform.

1. Get official source for ninja-1.3.4

git clone git://github.com/martine/ninja.git
cd ninja
# obtain latest release and verify its version number
git checkout release
git describe --tags
1.3.4

2. The latest wine-git version is a reliable build platform if you
stick to the basics, but sometimes you do run into issues if any build
is done by a method that is ordinarily not heavily used for most
projects.  This turned out to be the case for the recommended build
method which was "python bootstrap.py" which insisted I had a mvsc
environment (which is far from the case).  There must be some
Wine-related error in the system-introspection being done by that
script, and because of that issue, this build method was unusable on Wine.

3. So I switched to the tried and true CMake-based build method using
a CMakeLists.txt file I found at https://github.com/syntheticpp/ninja.
There is likely an excellent git method for installing just that file
on top of ninja-1.3.4, but my git skills are weak so I used wget
instead for downloading just the CMakeLists.txt file from
https://github.com/syntheticpp/ninja into the top-level "ninja"
directory containing the source code for ninja-1.3.4.

4. Create a symlink from DbgHelp.h in the wine install location to the
wine name for that header, dbghelp.h.  (I have written to the Wine
Developer list about this issue since to implement just the lower-case
version of the name of that header may be a Wine bug.)

5. Apply the following patches:

--- ninja/CMakeLists.txt_original	2013-06-08 21:51:18.022678648 -0700
+++ ninja/CMakeLists.txt	2013-06-08 22:50:58.049172455 -0700
@@ -162,9 +162,15 @@
          ${srcdir}/msvc_helper-win32.cc
          ${srcdir}/msvc_helper_main-win32.cc
          ${srcdir}/includes_normalize-win32.cc)
+    set(SYSTEM_HEADER_PATH)
+    find_path(SYSTEM_HEADER_PATH DbgHelp.h)
+    if(SYSTEM_HEADER_PATH)
+      include_directories(${SYSTEM_HEADER_PATH})
+    else(SYSTEM_HEADER_PATH)
+      message(FATAL_ERROR "Could not find System PATH where DbgHelp.h exists") 
+    endif(SYSTEM_HEADER_PATH)
  endif()

-
  if(browser)
      find_package(PythonInterp)
      if(PYTHONINTERP_FOUND)


--- ninja/src/minidump-win32.cc_original	2013-06-10 14:36:18.455671051 -0700
+++ ninja/src/minidump-win32.cc	2013-06-10 14:36:50.871048301 -0700
@@ -14,12 +14,10 @@

  #ifndef NINJA_BOOTSTRAP

+#include "util.h"
  #include <windows.h>
  #include <DbgHelp.h>

-
-#include "util.h"
-
  typedef BOOL (WINAPI *MiniDumpWriteDumpFunc) (
      IN HANDLE,
      IN DWORD,

That first patch allows CMake (in conjunction with setting
CMAKE_INCLUDE_PATH appropriately) to find the idiosyncratic location
of the system headers for my wine installation.

The second patch is absolutely crucial.  On the Wine version of
Windows at least, the windows.h and DbgHelp.h (a.k.a dbghelp.h)
headers interfere with the util.h header and created a broken build.
Reordering so that util.h was included first solved that issue.

6. Build ninja.exe using the "MSYS Makefiles" generator.  That worked
fine once the above patches were applied, and my recent experience
with "MinGW Makefiles" indicates that would have worked fine
to build ninja.exe as well.

I also built the ninja executable on Linux using the same CMake-based
method and the (default on that platform) "Unix Makefiles" generator.
That build finished without errors.

Those two builds gave me the opportunity to try out ninja on Linux and
ninja.exe on Wine to build software. The result is that for my test
case (builds for 5 different software projects) ninja is 14 per cent
faster on Linux than gmake, and ninja.exe is roughly a factor of two
faster than mingw32-make.exe from MinGW and roughly a factor of four
faster than make.exe from MSYS.  I will post more details about those
efficiency results in a separate message.

With regard to reliability, the ninja story is not quite as good.
ninja did provide perfect build results for the 5 projects on Linux,
and ninja.exe on Wine was fine on 4 of the 5 projects.  However that
combination exhibited a broken build bug on the fifth project which is
not present for "MSYS Makefiles" or "MinGW Makefiles".  That bug is
currently being discussed on the CMake developer list since it seems
likely, for the reasons I explain there, that I have discovered a
general CMake "Ninja" generator bug for the Windows platform (whether
Microsoft or Wine).  Of course, that conjecture requires verification,
but my post to cmake-devel contains a tarball attachment with a
complete simple "Hello World" style test case and results.  That
attachment should make it easy to verify (or not) this bug also occurs
on Microsoft Windows and if verified should also help developers
familiar with the code behind the "Ninja" CMake generator find and fix
the issue.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________