[CMake] Status/use of CMake on Cygwin

[Alan W. Irwin]

On 2013-05-19 21:06-0000 David Cole wrote:

>> 1. The CMake version at http://cygwin.com/packages/cmake/ appears to
>> be somewhat outdated.  The latest available package there is
>> cmake-2.8.9.  My impression is in the past the Cygwin package for
>> cmake was your work.  Is that still the case, do you plan to update
>> that package to CMake-2.8.10.2 (or 2.8.11) anytime soon?
>>
>> 2. If you are no longer involved with that package, can I just
>> download the Windows binary version of CMake-2.8.10.2 or later for use
>> on Cygwin?
>>
>> 3, Even if a binary version of CMake-2.8.10.2 or later is
>> available for Cygwin, I may build it anyway on that platform just for the
>> practice.  Are there any special build instructions
>> for that platform?
>>
>> 4. Which of the command-line generators should I be using on
>> Cygwin?  I assume it is one of the "* Makefiles" ones, but
>> which one?

> Answers to your numbered questions:
>
>
> 1. I don’t know -- Bill will have to answer this one.
>
>
> 2. No -- do not use the Windows binaries in the Cygwin environment. You have to use Cygwin cmake in the Cygwin environment.
>
>
> 3. Just use the bootstrap script, and treat it like a normal Linux/Unix environment. Make sure you have gcc/g++ for Cygwin installed first.
>
>
> 4. Use the “Unix Makefiles” generator. Just like on Linux/Unix.
>
>
> Disclaimer: I have found (over the years) the Cygwin environment to be ridiculously, enormously slow and frustrating, and have literally completely given up on it as a realistic development environment. I personally do not use it or install it, EVER. It’s probably been 3-4 years since I had one of my machines that had any form of Cygwin on it.
>
>
> So... take what I say with a grain of salt, but I believe my answers to be accurate despite my personal biases.

Thanks, Dave, for those detailed answers to my questions.

With regard to your frustration with Cygwin speed, I must say I have
similar frustrations with how fast commands execute under bash.exe.  That issue appears to be
entirely due to startup latency.  For example, here is a comparison of
"cmake --version" results on Linux versus running that same command
under bash.exe on Wine.

software at raven> time cmake --version
cmake version 2.8.10.2

real    0m0.008s
user    0m0.000s
sys     0m0.004s

bash.exe-3.1$ time cmake --version
cmake version 2.8.10.2

real    0m0.197s
user    0m0.000s
sys     0m0.040s

These results were determined with a CMake version I built myself on
Linux and a downloaded Windows binary (built by Kitware with Microsoft
proprietary compilers) on MinGW/MSYS/Wine, but in the past I have also
gotten similar bad results for a CMake version that I built myself on
MinGW/MSYS/Wine, and there are similar bad startup latency results
(0.2 seconds just to execute the --version option for the command
which is a factor of ~25 slower than the corresponding Linux result)
for all other heavily used build commands such as gcc and make.  So
this is a general bash.exe issue and not a cmake issue, and it a real
killer of build speeds since cmake and gcc are often invoked during
the build process (e.g., to provide progress reports, to make a quick
build test, or to actually make a build containing many separate small
source files ) in a way that is completely dominated by the bad
startup latency numbers above.

At this point I don't know whether this startup latency issue is due
to an issue with bash.exe on Wine or a more general bash.exe issue on
Windows, and if anybody hear could do such a simple "time cmake
--version" test for a MSYS/bash.exe environment on Microsoft Windows
to see whether the result is nearer 0.200 seconds or 25 times faster
that might confirm or eliminate Wine as the culprit.

Of course, with the Cygwin on Wine platform I will presumably be stuck
with this startup latency as well since bash.exe is part of that
environment. But I started working with computers when the Earth was
cooling (e.g., 1967), and those beasts were incredibly slow compared
to today's standards so I don't get overconcerned about inefficiencies
these days.  Instead, I will be pretty satisfied if I can report to
users of my software projects that I personally find no build or test
issues on any of the Linux, MinGW, or Cygwin platforms.

BTW. It just struck me while reading through this that I should do
some comparisons between "MSYS Makefiles" (which runs all its
subcommands under bash.exe) and "MinGW Makefiles" builds to see
whether the effect of startup latencies iare reduced in the latter
(since it does not use bash.exe internally).  However, I would have to
eliminate the tests from the comparisons since those (for all my
projects) are based on bash.exe scripts.

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
__________________________