[cmake-developers] Questions concerning using "MinGW Makefiles" when MSYS (without sh.exe) is on the PATH

[Alan W. Irwin]

On 2013-06-06 09:59-0400 Bill Hoffman wrote:

> On 6/6/2013 9:48 AM, Brad King wrote:
>> It looks like Bill added that check here:
>>
>>   http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=14cbc957
>> 
>> Bill, the commit message doesn't say why.  Do you remember?
>> 
>> The SHELL=cmd was present at the time the commit was made.
> I am pretty sure it failed.  Someone is welcome to try and see what happens 
> if you take out the check.

I will try to get to this in the next week or so if nobody else tries
that test with building their favorite software.  It would be great to
remove that "no sh.exe on PATH" requirement for "MinGW Makefiles" if
it turns out that does not affect the reliability of modern "MinGW
Makefiles" results.

Another piece of evidence concerning this issue is I just built the
current 5 (soon to be expanded to ~10 or so) projects configured by
build_projects and got identical good results for "MinGW Makefiles"
(with the sh.exe removal trick) and "MSYS Makefiles".  It turned out
the problem I had yesterday with "MinGW Makefiles" for one of the
projects being built was a cross-platform issue (I used mkdir rather
than the preferred CMake -E make_directory).  That issue is now fixed
so "MinGW Makefiles" builds configured with build_projects are
proceeding without issues.

To change topics slightly, build_projects can be used for
some interesting efficiency analysis.

Here is a comparison of the times for one part of that build:

# "Unix Makefiles" on Linux
wine at raven> time make VERBOSE=1 build_plplot >& build_plplot.out

real    0m24.584s
user    0m19.853s
sys     0m3.760s

# "MSYS Makefiles" on Wine
bash.exe-3.1$ time make VERBOSE=1 build_plplot >& build_plplot.out

real    3m50.691s
user    0m19.880s
sys     0m47.380s

# "MinGW Makefiles" on Wine
bash.exe-3.1$ time mingw32-make.exe VERBOSE=1 build_plplot >& build_plplot.out

real    4m8.106s
user    0m0.020s
sys     0m0.040s

where build_plplot just builds 4 PLplot dependencies (libagg, libharu,
libqhull, and shapelib) but not PLplot itself (yet). (This particular
test does not build ndiff, the extremely useful fuzzy diff tool
although that build configuration is available as well with
build_projects.)

On Wine "MinGW Makefiles" takes roughly 7 per cent longer to build
these 4 libraries than "MSYS Makefiles" from the above "real" timing
numbers.  I am a bit surprised by this result since I expected the
"MSYS Makefiles" result would use fork more often to start commands,
and fork implementations are notoriously inefficient (cause noticeable
command startup latency) on Windows platforms.  It's this Windows (not
specifically Wine) startup latency for commands that use fork that is
presumably causing the factor of 10 slowdown for the Windows builds
compared to the Linux builds.  This is an extreme case of the slowdown
because these builds and tests compile many small files and run many
different short test commands.  For test builds I have tried for other
projects (such as ephcom or te_gen) which contained long test
commands, the slowdown was only a factor of two or so which is why I
think the explanation of the slowdown as being due to fork
inefficiency and associated startup latency is probably correct.

It would be interesting to see the build efficiency of the jom or
ninja build tools in comparison with the above timing results.
However, I have not had experience with either of those build tools,
and my Windows platform expertise is pretty limited so I am not sure I
could get them to work on that platform in general and specifically on
the Wine version of that platform.  But I plan to give it a try
in both cases.

My understanding is ninja CMake support is still pretty experimental
on Windows.  Can somebody give me a quick cookbook of what to do
there, especially what version of ninja and what version of CMake
should work well together on Windows?

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
__________________________