[Gcl-devel] Cygwin and MinGW32

[Mike Thomas]

Hi Camm.

| Currently, GCL only supports MinGW32 as opposed to cygwin.
| Personally, I'd like to see both eventually supported, but our Windows
| expert vouches highly for the superiority of the former, and I defer
| to his judgement.

As this also came up recently, to help everyone understand my position I'll
do my semi-annual lecture:

1. Cygwin is great -  I use it to work sometimes on the Win32 port of the
GRASS GIS - both the XWindows and native windows display system variants of
that project.  Cygwin has made a lot of great Unix originating software
available on Windows and has allowed many projects which were inextricably
tangled with Unixy source code to be ported with minimum fuss.

BUT.... Cygwin dll dependent applications are difficult to distribute,
because more than one running instance of the DLL (due, for example, to two
different Cygwin dependent apps being distributed as standalone installers,
or one app and a standard Cygwin installation) causes trouble.  A common
solution is to get the end user to install Cygwin first and then to install
their brand new package into the Cygwin directory structure (Grass takes
this approach).  The problem, is that most Windows users can't or don't want
to know anything about Unix shells and/or Cygwin.  This leads to endless
support hassles for part-time open source contributors.  The whole approach
is also anathema to typical Windows end-users.  (Imagine having to install
Linux just to run one application.)


2. Cygwin can certainly be used to host both Cygwin dll dependent and normal
(ie not dependent on the Cygwin dll) Win32 software.  In fact, the Glasgow
Haskell compiler has for many years used Cygwin to host it's MinGW32 build.
The Mercury compiler has also taken this route.

BUT.... Even experienced developers struggle sometimes with getting GHC
built under Windows because of the subtle issues caused by file name format
differences, accidental compiler/library mixups etc.  Cygwin is a really
unpleasant way to host the building of native Windows targets.  It is quite
hard to remotely support workers with these kinds of problems.


3. MSYS is a relatively new fork of Cygwin which alleviates the infelicities
and setup hassles of the Cygwin system in a way which works well with the
native Win32 version of GCC -  MinGW32.  It really is much simpler for
relatively casual and also very experienced programmers to get down to work
on configuring and building native Windows applications which is what they
really want to do.


4. Maintaining both Cygwin and MinGW32 ports of GCL is fine, but someone has
to do it (and it won't be me).  There is plenty of overlap with the MinGW
version, but still, configuration options are different, the headers etc and
there are lots of detail differences.  Furthermore, someone also has to feed
and care for two Windows binary packages instead of one.  We really do need
more Windows people with their own machines and preferably more nitty-gritty
PEcoff knowledge than your humble correspondent for this course of action to
work well given the course of development GCL is on.


5. Finally and probably most importantly, a Cygwin version of GCL helps
almost noone if a native version already exists - end products such as
Maxima, ACL2, Axiom etc are much better off being distributed as standalone
native applications that anyone can install like a normal Windows program
rather than having to muck around with Cygwin dependency; much easier to
support in a volunteer driven software factory!

Cheers

Mike Thomas.