Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>,
	<http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Date: Tue, 17 Aug 1999 22:26:10 -0700 (PDT)
From: "Jon M. Taylor" <taylorj AT gaia DOT ecs DOT csus DOT edu>
To: cygwin AT sourceware DOT cygnus DOT com
Subject: An irritated cygwin newbie
Message-ID: <Pine.HPP.3.91.990817203627.20109A-100000@gaia.ecs.csus.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	I am a member of the GGI project (www.ggi-project.org).  Our
standard-bearer is LibGGI, a dynamic library based cross-platform graphics
and event library and API system.  I want to port LibGGI to win32/DirectX,
so naturally I thought that cygwin would be a great help to me.  I now
have serious doubts about that, and am planning to fall back to a native
port.  Although a native port will require a lot more work in the 
short-term, I do not feel comfortable relying heavily on cygwin anymore.  
Why?  Read on....

	Around four hours ago I downloaded the latest "stable" (ha!)
release, b20.1.  I was a bit nervous about using such an old release, but
I didn't want to play with snapshots on a project as huge and complex as
cygwin.  So, I downloaded full.exe and installed it.  I then downloaded
autoconf, automake and libtool, I figured that, since cygwin comes with
GNU M4 and /bin/sh all nicely set up, there couldn't be any problems. 
Yeah right.  I had been bitten by the "/bin/sh is ash" bug.  No info about
this in the FAQ.  After searching the mailing list for every keyword I
could think of (the list archives at www.cygnus.com are quite broken BTW),
I finally found out:

* /bin/sh.exe is actually ash, which is not POSIX-compliant.  The weird 
errors I was seeing when I tried to run .configure were ash improperly 
quoting strings. Copying bash.exe to /bin/sh.exe fixed all my problems.

* This problem has been know about since a few weeks after b20.1 was 
released, which was last December.  Nobody has fixed it, released a new 
cygwin with /bin/sh symlinked to bash.exe, or even updated the FAQ.  ash 
was apparently used 'because it is faster than bash' (direct quote from 
the mailing list).  As if speed could ever be justifiably be a higher 
priority than formal correctness on a system API emulator??....

* b20.1 has been know to be badly broken in a lot of places for quite some
time now, so much so that people appear to be forced to either stay with
b19 or use the bleeding-edge snapshots in order to get anything to work
properly.  Again, this is not mentioned anywhere on sourceware.cygnus.com
or the FAQ.  Patches and workarounds for the problems with b20.1 are
piling up, with no release date for a b21 in sight.  People are routinely
advised to fix their problems with b20.1 by downloading CVS snapshots. 

	This is not the way to do things, folks.  If a supposedly-stable
release goes out the door and a nontrivial bug is discovered (and IMHO the
sh-is-really-ash thing qualifies), you fix the bugs _first_ before going
off and starting a bunch of major new changes in CVS, leaving people with
no choice other than to stick with a quite old release (b19) or be forced
to use bleeding-edge CVS snapshots.  I find it odd that b20.1 was released
specifically to fix bugs in b20 (released two months previously), but then
we get a period of _nine_ months now where many serious bugs with b20.1
have been reported, and yet there is no b20.2 available and b21 looks like
being released later rather than sooner.

	"Beta" implies, if not the formal software-engineering definition
of "only bug fixes, no new features" (few projects stick to that
rigorously), at least that bug-fixes and stability in general take
priority over new features.  That certainly does not appear to be the case
right now with cygwin, the 'b' on the releases notwithstanding.  I've seen
many alpha releases from many open-source projects which are far more
stable than the supposed beta release of b20.  In fact, it is quite
obvious that the alpha development period of cygwin is far from over. 

	I am surprised to see the software engineering process of a
commercially-funded open source project of this size and complexity in
such disarray, all the moreso since the EGCS people are also funded by
Cygnus and the stablity, regularity and timeliness of their snapshots and
stable releases have always been outstanding.  I had thought that I would
also find this level of quality in the cygwin project, but it appears that
I was mistaken.

	I ported LibGGI to a GNU emulation environment on the __AMIGA__
that was *considerably* less of a hassle to get set up and running than
cygwin was!  That's not a good sign.  I strongly urge those in change of
this project to put whatever they are working on on the shelf for a while
and focus on cleaning up all the ratty loose ends of this project before
it all unravels on them.  I will be putting my LibGGI win32 port on the
shelf as well, until I see a new "stable" release of cygwin that is
verified stable by lots of users over an extended period of time.  If 
this does not happen soon, I may have to bite the bullet and do a native 
port |-<.


Disappointed as all hell,
Jon Taylor

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com