From: JonY <jo...@us...> - 2011-06-02 05:59:04
|
On 6/2/2011 09:39, Xiaofan Chen wrote: > On Thu, Jun 2, 2011 at 12:08 AM, Charles Wilson > <cwi...@us...> wrote: >> On 6/1/2011 8:15 AM, Xiaofan Chen wrote: >>> Is this really worth the efforts? >> >> Well, are you asking if porting bash-4.x to current msys is worth the >> effort? Dunno: what's the amount of effort required? What's the value >> of the result? Can't answer that until somebody tries it. >> >> 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? What does this really mean? At least it does > produce binaries not relying on cygwin1.dll, right? > Yes, MinGW(-w64) based toolchains produce executables that do not rely on any cygwin1.dll. >> Many packages are not "cross-compiler" friendly. And, it becomes >> difficult/impossible to run the automated test suites when using a cross >> environment. I think test suites are valuable -- so "native" >> compilation is a good thing. MSYS provides that capability for the >> native mingw compiler (and the mingw64 ones, as well). > > I see. > > 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). > That's right, Cygwin based toolchains don't work well under native win32 IDEs or build system mostly because of the path translation. > For me, the main benefits now with MSys compared to Cygwin is > probably speed. But cross-build under Linux is actually faster. > The other thing is MSys is smaller than Cygwin but now it is not > really an issue with bigger harddisks. > The speed difference is arguable, I've heard the opposite, but it runs about the same for me. > 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. > Well, to me, using an IDE to build is an alien concept, autotools provide a very sane interface, it is especially good for cross compiling, unless the person who wrote configure.ac botched it big time. >> I dabble in both worlds, and MSYS provides a number of features that >> cygwin does not, including better interoperability with native tools -- >> like these native compilers. However, cygwin has added a number of >> features lately (see link above) that should make the "delta" between >> cygwin-$new and msys-$next much smaller (but not zero). That's a GOOD >> THING, not a bad one... >> >> The question is, tho, is it worth the effort of creating this msys-2.0 >> beast, or sticking with our current baseline and incrementally improving >> it? I don't know the answer -- but I do know we're not going to worry >> about it until mingw-get leaves alpha, and we have a good start on its >> gui version. There are a lot of kinks yet to work out in that, and dev >> resources are not infinite. >> >>> 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! > I did bash-4.0 a long time ago when gcc 2.95 was the norm for MSYS, it works fine (assuming most stuff was statically linked), but I haven't really enabled all the extra bells and whistles features. I just added -D__CYGWIN__ when doing it under msys, not sure if I used any Cygwin specific patches. I have in my MSYS at the moment: $ bash --version GNU bash, version 4.0.0(1)-release (i686-pc-cygwin) bash-4.2 came out a bit broken, with line wrapping strangely broken in rxvt (there was no mintty at the time, the win32 console sucked). >>> 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. > That's a pretty loaded statement there. |