From: Charles W. <cwi...@us...> - 2011-06-02 13:50:25
|
On 6/1/2011 9:39 PM, Xiaofan Chen wrote: > On Thu, Jun 2, 2011 at 12:08 AM, Charles Wilson wrote: >> Are you asking if creating a new msys-2.0 based on modern cygwin is >> worth the effort? Again: dunno: what's the effort required? The value >> is obvious -- IF you accept the need for msys at all, rather than >> relying on a cygwin environment and using their cross compiler(s). > > This is actually more in line with my question. So you are saying > that MinGW under Cygwin is a cross compiler and not a native > compiler, right? No, that's not what I am saying. Early this morning, cygwin published a set of cross-compiler tools based on our MinGW compiler: http://cygwin.com/ml/cygwin-announce/2011-06/ For instance, it provides "i686-pc-mingw32-gcc.exe" which is a *cygwin* application, that understands unix (cygwin) paths, and generates MinGW (that is, native windows, not cygwin) libraries and applications. > What does this really mean? At least it does > produce binaries not relying on cygwin1.dll, right? Our compiler, the MinGW gcc, is a native windows applications, that understands only Windows (dos-style) paths, and generates MinGW (that is, native windows, not cygwin) libraries and applications. Niether the compiler itself, nor the programs/libraries it generates, depend on cygwin1.dll nor on msys-1.0.dll nor any other posix emulation DLL (well, except for Pthreads-Win32, but that's a different issue). Now, the "problem" with our compiler, is that a lot of automatic configuration tools out there require a set of unix-like utilities. "configure" scripts need a (unix) shell implementation. They also depend on tools like awk, sed, and grep. Furthermore, many build systems employed by projects that are developed on unix, assume that paths are and always will be "unix like" and not "dos like" -- and tend to croak when presented with dos paths ("C:\foo\"). That's where MSYS steps in. It provides all those unix utilities that configure scripts and build systems expect. So, even though it, itself, is a unix emulation environment -- it "pretends" to be native windows. That is, uname typically reports MINGW32_NT -- and universally, upstream unix tools have been taught to recognize this as the i686-pc-mingw32 platform -- that is, native windows (not an "msys" platform). That's step one. The other service that MSYS provides is that, when msys tools (like bash) execute a program, msys automatically detects whether that tool is also an msys program (in which case nothing /special/ happens), or if that tool is actually a native windows program, like MinGW gcc.exe. In THAT case, MSYS knows to automatically scan the argument list for anything that looks like a unix path, and convert it to DOS format before passing it on to the (windows) tool. This way, the build system tools -- written on unix and which expect and generate unix paths, are "happy" because they can keep working the way they are used to. BUT, the windows tool (e.g. MinGW gcc.exe) is "happy" because it only sees the DOS-style paths IT wants. That's step two. Together, this means that MSYS allows to use a "native" compiler like MinGW gcc.exe with build frameworks (autoconf, etc) that expect unix-like behavior. The build is treated like a "native" compile -- so test suites will not be skipped (as they typically are in all "cross compile" situations: you can't run an HPUX test app if you're cross compiling on a Solaris box, can you?) > I understand that a standalone MinGW toolchain is good so that > people can use it with different build systems and IDEs. And it is > not so convenient to use the Cygwin MinGW package (when it is > available). > > For me, the main benefits now with MSys compared to Cygwin is > probably speed. But cross-build under Linux is actually faster. This is probably true, but nobody has actually quantified it. > The other thing is MSys is smaller than Cygwin but now it is not > really an issue with bigger harddisks. > > With a standard MinGW toolchains, then probably MSys is good > to have as well. > > To me the main use of MSys (or Cygwin) is when porting Linux > software which rely on the old/bad autotools which are foreign to > many Windows developers. Better build system is long overdue > but unfortunately the new ones (eg Cmake) are not really much > better. Microsoft's IDE seems to be much easier to use. This is a religious issue. I'm not going to debate build systems with you, except to note that there are literally THOUSANDS of projects out there that use the autotools, and we MUST support it or those projects will be VERY difficult to build using the MinGW compiler (write a CMake build script from scratch for project FOO, specifically for use on win32, when project FOO already has a perfectly serviceable build system in place?) >>> Cygwin already has bash 4.x and the only thing needs to be >>> done is to have a MinGW compiler package within Cygwin >>> to take use of the work of Cygwin. >> >> This will be published later today. > > That is great! Note that it IS possible to use our native MinGW gcc from within a cygwin environment -- BUT there are two drawbacks: #1) you have to explicitly configure as --host=i686-pc-mingw32 AND override $CC (CC="/cygwin/path/to/mingw/bin/gcc.exe"), among numerous other little tweaks. This means that the build is treated as a cross compile -- so without special steps, running test suites is usually suppressed. #2, no automatic path translation, so you have to jump through special hoops (like so called "unity mounts" -- use google) in order to "fool" MinGW gcc.exe into accepting unix paths and interpreting them correctly (as DOS paths!). There are also other 'gotchas'. This is a BIG pain, but many people have done it for years. However, with the new cygwin-hosted cross compiler, it's much more streamlined to simply use THAT, if you want to stay in the cygwin world. And, of course, using MinGW gcc.exe via MSYS is supported as usual, as the "native" environment for MinGW. >>> Take note MinGW-w64 >>> has already has packages for Cygwin (i686 and x86_64). >> >> Right, but those are based on different Win32 API libraries and headers, >> and different runtime support than MinGW.org's. There are reasons for >> this, which we don't need to get into, in this thread. However, given >> that there ARE differences, it makes sense for both to be available (as >> cross compilers on cygwin, and as native toolchains). > > Totally agree. Personally I still think MinGW is more reliable/stable than > MinGW-w64 and use MinGW-w64 only for 64bit build. Again, a religious issue. Not going there. -- Chuck |