On Jun 11 12:58, Ray Donnelly wrote: > I for one am hugely appreciative of all the hard work that Corinna, Kai, > redhat, the mingw-w64 team and also Alexey has put into both Cygwin and > MSYS2. > > Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we
I fail to see that. MSYS2 is basically to run a Mingw compiler and to have a POSIX-like shell. How is that something Cygwin doesn't provide anyway?!? > can reasonably do on MSYS2 (credits, thanks printed at each login, > explanations of where MSYS2 comes from and links to Cygwin etc) to make the > fork-pill easier to swallow, I'm sure Alexey will be happy to do (though I > can't speak for him of course!) > > MSYS itself was a fork of Cygwin ages ago, and it's really showing its age. > If you accept that there's any value in MSYS, then I hope you can see the > need we in the MSYS using section of the mingw-w64 community have for an > updated versoin. As an example, we can't build Qt with MSYS because MSYS > Perl is at version 5.8.8. MSYS itself was badly fragmented by the msysgit > project which uses an even earlier version of MSYS than the latest one > which is also missing important tools such as "install.exe" and something > has to be done to improve this situation. Our hope is that MSYS2 can be > adopted by that project and that MSYS never rots as badly as it has done. > > If we can get down to a proper technical discussion on what's different and > why, then we can maybe think about some way of working together? > > So many thanks everybody for the hard work and dedication. My stance is that everything you can do with MSYS2 you can do with Cygwin anyway, so the reason for the fork escapes me. If it's all about symlinks as copies, then I think this was a really bad idea from the start. In the old times Cygwin did the same (albeit not recursively) when creating hardlinks on FAT and FAT32. But that was a bad idea from the start as well, which is why later versions of Cygwin returned an error EPERM instead. So, yes, I'm more than willing to discuss the technical reasons for forking Cygwin, but there's nothing yet which couldn't be handled by a change to the environment setup alone. Alternatively, I could understand if you would build some micro-distro around Cygwin which handles the default setup of the environment differently so it's more matching your Mingw workflow. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
