On Wednesday, October 7, 2015 at 11:27:25 PM UTC+2, Bill Hart wrote: > > OK, after more reading I find that these are the main benefits of MSYS2 > over Cygwin: > > * Support for interop with mingw-w64 built packages. > * Ability to switch from MSYS to MinGW mode by setting an environment > variable (MSYSTEM). > * Automatic conversion on the fly in the msys2.0.dll between different > path formats. > * Automatic handling in the msys2.0.dll of the different line endings > (posix vs Windows). > * A direct recompilation of the Arch Linux package manager (Pacman). > * Various other more technical things. > That's right. See: * http://sourceforge.net/p/msys2/wiki/How%20does%20MSYS2%20differ%20from%20Cygwin/
In fact, there would even be a possibility to have a unique project offering both features but communication seems to be complicated between the two parties. * https://github.com/Alexpux/MSYS2-packages/issues/83 * https://cygwin.com/ml/cygwin/2014-12/msg00143.html > > The main benefit as explained by an MSYS2 person is that with MSYS2 you'll > use a lot more natively compiled binaries, which will be faster. > I'm not sure that's completely true nor what natively really means. What's sure is that whatever uses the POSIX compatibility layer (whether it is called cygwin1.dll or msys-2.0.dll) will surely sacrifice performance. So the real performance deal is rather to use the mingw-w64 compiler to compile without POSIX compatibility or the cygwin(32/64)/msys(2) and get POSIX compatibility through an "emulation layer". > The main benefits over MinGW are: > > * It's actually being developed. > * It is regularly synced with the Cygwin project. > * MSYS2 bash is not inferior to Cygwin bash. > > Note sure if you mean the old mingw(32?) project (http://www.mingw.org/) or the mingw(-w?)64 (or whatever it's called, http://mingw-w64.org/doku.php). One of the main goal of MSYS2 is "just" to offer the possibility to run autotools and gcc-*-*-*-*-*-mingw(-w64) from a shell on Windows. Remark you can also cross compile from Linux using mingw(32/64) and even run tests from Linux using Wine(64)! Or "cross-"compile from Cygwin using mingw-w64 and run tests form a Cygwin shell :p ! So I guess that in the end, anyone should use the environment it prefers to compile his stuff, but the produced result will mostly depend on the compiler used and need for POSIXness: * either POSIX compatibility is needed and then one needs cygwin1.dll or msys-2.0.dll (the latter one seemingly interacting better with Windows filesystem naming convention, the former with the POSIX naming convention), * no POSIX compatibiliy is needed and then the way to go is mingw-w64 (or MSVC!). The real deal is to make sure that both kind of produced libraries can communicate and that's not trivial when they assume that long's are of different sizes, some evil header magic has surely to be involved. Fortunately, both kind of produced libraries use the same function call ABI (the (thanks Microsoft to have created your own ABI) Windows 64 one: https://msdn.microsoft.com/en-us/library/ms235286.aspx, different from the more usual system v one, see https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions and http://stackoverflow.com/questions/4429398/why-does-windows64-use-a-different-calling-convention-from-all-other-oses-on-x86), otherwise interoperability would have been even funnier to achieve. Best, JPF -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
