From: khan AT xraylith DOT wisc DOT edu (Mumit Khan) Newsgroups: comp.os.msdos.djgpp Subject: Re: fall of rsxntdj?? Date: 1 Sep 1999 04:43:34 GMT Organization: Center for X-ray Lithography, UW-Madison Message-ID: <7qiatm$dm8$1@news.doit.wisc.edu> References: NNTP-Posting-Host: modi.xraylith.wisc.edu Lines: 49 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com In article , Eli Zaretskii wrote: > >The point is that those 10% can e.g. prevent you from building a >package, and the problems are so subtle that the average John Doe the >Programmer can spend days on end without finding a solution. I agree with this. Let's wait till Cygwin b21 and revisit this issue again. > >The problem is they are all subtly incompatible, and a lot of effort went >into making all that hodgepodge of programs work together in concert. > >A coherent package such as DJGPP or Cygwin solves these problems. Absolutely. It already works very well under Cygwin (either as a Cygwin subtarget or as a full fledged cross-compiler capable of rebuilding itself). But as you point out, Cygwin has kinks to work out. >No argument here. My message wasn't meant to suggest that you alone >should do the work. It was meant to suggest a way to make Mingw a better >development environment by tracking the path charted by DJGPP, and >encourage interested people to start moving Mingw in that direction. The big problem is that some of the essential utilities required for a GNU-style development environment will be very hard to port to a minimal (no pun intended) environmnet like Mingw (which stands for Minimalist Gnu-Win32), and bash is the prime example. We'll always need a "host", and currently the preferred ones are Cygwin and UWIN. If DJGPP folks want to use it, the path I suggest is to use the rest of DJGPP's very established tools with Mingw compiler/binutils. I don't know anything about how DJGPP works, but if it does how it expect it to (from all I've heard about it), the only challenge would be to fix the pathnames to use 8.3, which may or may not be trivial. I'm willing to help if there is need. Till then, I do believe that RSXNTDJ should be revived first to see if it does indeed fit the requirements, and if so, just use that. Nothing like known existing tools to get the job done. New tools, no matter how promising, always brings extra baggage. Regards, Mumit