Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <3AEE2E6F.1044C4C6@ece.gatech.edu>
Date: Mon, 30 Apr 2001 23:33:03 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: Andy Piper <andyp AT bea DOT com>
CC: cygwin AT cygwin DOT com
Subject: Re: When will cygwin ever be stable?
References: <4 DOT 3 DOT 2 DOT 7 DOT 2 DOT 20010430105401 DOT 00eb8220 AT san-francisco DOT beasys DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andy Piper wrote:
> 
> Don't get me wrong - I love cygwin and think Chris and co have done a
> marvellous jobs, but as a user who simply wants cygwin to work well I have
> never installed a version that actually has all the signifcant bugs
> squashed. 

This is true.  I've had the same experience with the Linux kernel
2.2.10, 2.2.13, 2.2.14, 2.2.16, and 2.2.18.  And don't get me started on
2.4.0-testX, 2.4.0, 2.4.1, 2.4.2, ...

> Each time I install, something might be fixed but something else
> breaks. For instance C-c - using C-c in cygwin is completely fundamental to
> its usability and yet it has been fairly broken in the last two versions I
> have installed (1.1.8-2 and 1.3.1);

You are unfortunately correct about the ^C issue.  However, (and this is
the really strange thing) it got fixed in the snapshots *prior* to 1.3.1
IIRC, but then broke AGAIN at 1.3.1...but is NOW fixed (again) in the
snapshots.  I think.  :-P

> the headers change the whole time so
> that trying to maintain anything that builds under cygwin is a complete
> nightmare.

(I harp on building non-cygwin apps with cygwin extensively; the reason
for that is made clear several paragraphs down):

Well, no.  What has gone through a lot of *disruptive* changes recently
is not the cygwin kernel itself (although the kernel has changed
substantially, those changes have not been, by and large, disruptive). 
Cygwin's gcc has changed a lot, and the "w32api" headers have changed --
that has caused havoc with building non-cygwin (e.g. -mno-cygwin) apps. 
If you want to build "pure" cygwin apps, it's been pretty stable (I know
-- I maintain a LOT of the application packages for cygwin).  However,
if you try to build something that's pure windows (no cygwin1.dll
reliance) then -- yeah -- it's been hell recently.

Part of that is because (a) mingw, upon which a lot of the pure windows
support is derived, had a period of roughness there for a while, (b) the
w32api was practically unmaintained for a year or more; we've been
sync'ing up with the "good" version over the last several months and the
mingw folks are really picking up steam, (c) in an attempt to make the
separation between pure-cygwin headers and pure-windows headers, stuff
has moved around [this had ripple effects out to gcc and binutils,
things are still shaking out now], and FINALLY, (d) the -mno-win32 /
-mwin32 default change to gcc is still causing a ripple effect [IMO, the
fact that THAT change is causing problems is indicative of poorly or
incompletely ported apps, but...]

Another part of the problem is w.r.t -mno-cygwin is, well, the NO-CYGWIN
part.  There's enough to do adding features and fixing bugs just in
cygwin and its associated packages (70 or 80 at last count) for the 10
or so developers and package maintainers.  The reason for keeping the
NO-CYGWIN part of the cygwin toolchain working is just that a lot of
people use it -- but since extremely few of those people (none?), who
use cygwin as a toolchain for non-cygwin apps, actually contribute to
the cygwin project itself,

well,

that makes maintaining the NO-CYGWIN part of the cygwin toolchain
completely altruistic.  And altruism, coupled with constant complaints
without assistance, eventually wears thin.  Right now, if it weren't for
the fact that cygwin's setup.exe (and certain other parts of the cygwin
kernel itself) requires the NO-CYGWIN stuff to work -- if it weren't for
that, I think the developers of cygwin would drop NO-CYGWIN support
completely in a New York minute, and tell everybody who wanted it to
install mingw.

> I could go on, but the point is that all of these features have
> worked at one time or other, but there doesn't seem to ever be a release
> that squashes them all. Am I hoping in vain?

Short term pain for long term gain?  Maybe?  We hope?  8-j  (sometimes
it DOES seem like squeezing a balloon or playing whack-a-mole, doesn't
it...)

Anyway, Andy, I know that you recently adapted cygwin's setup (e.g.
"cinstall") for use by XEmacs.  Since setup is a pure-windows app, it
got hit by the gcc/specfile/headers-moving-around problems -- and even
some w32api changes.  You may want to take a look at this patch:

http://www.cygwin.com/ml/cygwin-patches/2001-q2/msg00114.html

which was necessary to keep *cygwin's* version of setup.exe working...

--Chuck

P.S. I know you mean to be *contructively* critical of cygwin, and that
you've been a loyal cygwin'er far longer than most of the rest of us. 
In fact, you're the inspiration behind my usr-local package for cygwin
V1.1
(http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/usr-local/) --
your usrlocal package for B20 made cygwin really usable.  Of course, my
usr-local for V1.1 has dwindled as I've migrated most of 'my' packages
into the core cygwin dist.  So, all cygwiners owe you a debt of thanks,
and should take comments by a long timer like yourself with a certain
seriousness. 

OTOH, Chris is right -- we can try to fix *specific* complaints, but
"cygwin isn't stable" is a bit too general...

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple