From: Earnie B. <ear...@ya...> - 2002-08-26 15:13:47
|
Does someone else want to chime in? If I see nothing else by the end of the day, I'll give my opinions. Earnie. Christopher Faylor wrote: > On Mon, Aug 12, 2002 at 12:34:09PM +0530, Ranjit Mathew wrote: > >I recently (and successfully, I might add) built ACE 5.2.1 with MinGW > >1.1 and MSYS 1.0.7 using the build instructions given in the ACE docs. > >The docs however, refer to a CYGWIN/MinGW combo setup with its > >associated problems - it was far simpler and quite straightforward to > >use MSYS instead! > > Out of curiousity what "associated problems" are there with cygwin? If it's > just the problems with -mno-cygwin then recent test versions of gcc should > eliminate all of them. > > I'm always interested in hearing how msys solves a problem since as far > as I know MSYS is based almost entirely on cygwin. > > And, as I've previously stated, I'm not wild about the idea of this msys > fork although it certainly falls within the rights of free software to > provide it. > > cgf > (Mr. Cygwin) > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Luke D. <cod...@ho...> - 2002-08-27 01:22:48
|
MSYS is intended to provide a POSIX build environment for the Mingw compiler, primarily to allow 'configure' scripts to run and produce mingw32-hosted executables. Cygwin provides a build environment that is best suited to the Cygwin compiler, and in the past support for creating non-cygwin-dependent executables has been fairly limited (e.g. libstdc++ dependent the cygwin DLL). If you believe that -mno-cygwin eliminates the need for MSYS, then you must believe that there is no need for the Mingw compiler at all, unless you mean that users should install both the Cygwin compiler (for configure script style software) and the Mingw compiler (for MSVC style software). MSYS differs from Cygwin mainly in the way it translates POSIX paths to Win32 paths in arguments passed to native Win32 programs (and not MSYS-dependent programs). MSYS also provides a 'uname' command that allows scripts to automatically detect that the host environment is 'mingw32'. Luke Dunstan ----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Cc: <min...@li...> Sent: Monday, August 26, 2002 11:14 PM Subject: [Mingw-msys] Re: [Mingw-users] [OT] MSYS? (WAS: Re: Problem compiling ACE/TAO with MingW) > Does someone else want to chime in? If I see nothing else by the end of the > day, I'll give my opinions. > > Earnie. > > Christopher Faylor wrote: > > > On Mon, Aug 12, 2002 at 12:34:09PM +0530, Ranjit Mathew wrote: > > >I recently (and successfully, I might add) built ACE 5.2.1 with MinGW > > >1.1 and MSYS 1.0.7 using the build instructions given in the ACE docs. > > >The docs however, refer to a CYGWIN/MinGW combo setup with its > > >associated problems - it was far simpler and quite straightforward to > > >use MSYS instead! > > > > Out of curiousity what "associated problems" are there with cygwin? If it's > > just the problems with -mno-cygwin then recent test versions of gcc should > > eliminate all of them. > > > > I'm always interested in hearing how msys solves a problem since as far > > as I know MSYS is based almost entirely on cygwin. > > > > And, as I've previously stated, I'm not wild about the idea of this msys > > fork although it certainly falls within the rights of free software to > > provide it. > > > > cgf > > (Mr. Cygwin) |
From: Ranjit M. <rm...@ho...> - 2002-08-27 04:24:22
|
Hi, Well, I was the poster of the mail to which "Mr Cygwin" has thus responded. ;-) The "associated problems" I was talking of was certain gotchas, especially those relating to PATH and the confusion between using "//c/xyz" and "c:/xyz" for various things, depending on which toolset was interpreting it. As for MSYS v/s Cygwin, I guess he's a little rattled that the MSYS+MinGW combo completely obviates the need for Cygwin for most of the people. ;-) Since both toolsets have a large set of goals in common, it makes sense for both of them to work together as much as is possible while forking off where they differ. What's wrong with that? I want a good and free set of development tools on Windows that works well with other Windows applications and technologies - and MinGW gives me this (almost there). MSYS gives me a nice and very powerful programming environment and the UNIX tools that I've grown fond of and making sure that most "configure"-based software works either out of the box or with minimal changes. My own experience with trying to build GCJ are a strong case in point for this. I'm one of those people who are "wild about this MSYS fork". :-P FYI, I was one of the earliest adopters of the Cygwin toolset. Though it was great, it tried to completely hide the Windows environment from me and had the "cygwin.dll" baggage - the "no-cygwin" thingy is, at best, a kludge, IMHO. Cygwin might be great for porting applications originally developed for POSIX-y environments, but for developing fresh applications, it just doesn't cut it! Not every Windows application in the world is a port you see. From Mumit's times, I have stuck with MinGW, so I might not be aware of "advances" made by Cygwin in integrating better with Windows, if any. My 2p. Sincerely Yours, Ranjit Mathew. Earnie Boyd wrote: > Does someone else want to chime in? If I see nothing else by the end of the > day, I'll give my opinions. > > Earnie. > > Christopher Faylor wrote: > > >>On Mon, Aug 12, 2002 at 12:34:09PM +0530, Ranjit Mathew wrote: >> >>>I recently (and successfully, I might add) built ACE 5.2.1 with MinGW >>>1.1 and MSYS 1.0.7 using the build instructions given in the ACE docs. >>>The docs however, refer to a CYGWIN/MinGW combo setup with its >>>associated problems - it was far simpler and quite straightforward to >>>use MSYS instead! >> >>Out of curiousity what "associated problems" are there with cygwin? If it's >>just the problems with -mno-cygwin then recent test versions of gcc should >>eliminate all of them. >> >>I'm always interested in hearing how msys solves a problem since as far >>as I know MSYS is based almost entirely on cygwin. >> >>And, as I've previously stated, I'm not wild about the idea of this msys >>fork although it certainly falls within the rights of free software to >>provide it. >> >>cgf >>(Mr. Cygwin) >> >>------------------------------------------------------- >>This sf.net email is sponsored by: OSDN - Tired of that same old >>cell phone? Get a new here for FREE! >>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 >>_______________________________________________ >>MinGW-users mailing list >>Min...@li... >> >>You may change your MinGW Account Options or unsubscribe at: >>https://lists.sourceforge.net/lists/listinfo/mingw-users > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 |