[CMake] Cygwin drive paths are killing me

[Alan W. Irwin]

On 2014-06-14 12:25-0400 David Cole wrote:

> The difficulty of uninstalling it, and the difficulty of replicating a
> cygwin environment that is on one machine *exactly* on another machine
> with *all* the same components at *all* the same versions ... these are
> but 2 of the reasons I will NEVER rely on cygwin again for anything.
> It's just too painful, and there's absolutely NO upside.

Hi Dave:

Why are you holding back so much from giving us your real opinion of
Cygwin?  :-)

Seriously though, I wonder if some of your complaints have an answer.
I don't have any experience with Cygwin myself (see below), however,
if you used a unique install prefix for Cygwin, wouldn't it be a lot
easier to uninstall?  Also, your complaint concerning Cygwin
consistency is probably well taken since it is a constantly upgraded
so-called "rolling" distro (just like, e.g., Debian testing in that
regard).  But the day-to-day changes in Cygwin are small so if you
used a script to update Cygwin on the same day for all your different
machines, most likely you would get completely consistent results
installed on all those machines.  And then at that point I would leave
it alone until you needed to do a consistent Cygwin upgrade on all
your machines again.

Also, I think it is important for Windows users to have access to Unix
distributions (plural) of free software, where "Unix" refers to
containing all the core command-line Unix tools that Unix developers
know and love, and distribution is defined as a substantial body of
software beyond those core tools that is built with a consistent set
of (Unix) build tools.

If you accept that premise, then Cygwin is a really important example
of such a Unix distribution, and the only other competitors for it
that I am aware of at the present moment on Windows platforms are (1)
MinGW+MSYS (a much simplified fork of an ancient Cygwin version) and
(2) MinGW_w64+MSYS2 (a much simplified fork of modern Cygwin).

My only experience so far has only been with MinGW+MSYS.  It does have
a convenient automatic installer (see
<http://sourceforge.net/projects/mingw/files/Installer>, but
MinGW+MSYS has a very limited set of free software libraries available
so, for example, I find it necessary to build a lot of additional free
software libraries to provide soft dependencies of PLplot that
substantially enhance the power of PLplot.

My opinion is that MinGW+MSYS days are numbered because
MinGW_w64+MSYS2 reportedly fixes bugs much quicker (for example, the
long-standing MSYS bug that makes parallel builds with the MSYS
version of make unreliable), gives access to 64-bit versions of free
software, and also has many additional free software libraries
available compared to MinGW+MSYS. MSYS2 has an automatic installer
that is based on the ArchLinux pacman (see
<http://sourceforge.net/p/msys2/wiki/MSYS2%20installation/> and which
is completely different than the MinGW+MSYS automatic installer.

I currently cannot access either Cygwin or MinGW_w64+MSYS2 because I
use the Wine version of the Windows platform, and that has at least
two bugs that make it currently impossible to install Cygwin.  The
same two Wine bugs are also a showstopper for MinGW_w64+MSYS2
(presumably because of its similarities with modern Cygwin).  However,
my PLplot colleague has had virtually complete success with Cygwin.
Furthermore, when he has more time I will also encourage him to try
MinGW_w64+MSYS2 since apparently there are quite a few free software
libraries that are available for that Windows distribution of Unix
software.

Dave, I well understand that since you have had trouble in the past with Cygwin
it is all too easy for you to completely give up on it.  But I thought I should add my
own suggestions and feelings to balance yours for those here who would
like to give Cygwin (or MinGW+MSYS or MinGW_w64+MSYS2) a try without
being too affected by our different prejudices.  :-)

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
__________________________