Mail Archives: cygwin/1999/08/18/21:20:23
GGI does compile with Cygwin and I have not noticed a performance
loss (or a drastic perfomance loss).
John Fortin (fortinj AT ibm DOT net) had been working on writing
DriectX interface (libGII) for GGI.
Your statements about Win32 port of GGI contradicts Marcus Sundeberg
statements. Are you speaking your own thoughts or on behalf of whole
ggi-projects?
By the way, I do not think you can do a 100% native port of GGI to Win32
because all the libGII input stuff uses Unices... You will have to rewrite
the
whole libGGI and 75% of libGGI.
Regards
Suhaib
> 5) Given that Cygwin is an emulation layer I can't imagine why you would
> consider porting GGI using it. There will be inavoidable slowdowns
> which I would think would be unacceptable given the nature of what
> it is doing.
>
> I am grateful that you took the time to outline the problems that you
> see with the project. I wish we had more time to devote to getting a
> release out.
>
> Maybe if I stopped reading this mailing list, that would help a little...
>
> cgf
>
> On Tue, Aug 17, 1999 at 10:26:10PM -0700, Jon M. Taylor wrote:
> > 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
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
>
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
- Raw text -