-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11.06.2013 16:04, Corinna Vinschen wrote: > On Jun 11 15:43, LRN wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 11.06.2013 15:26, Corinna Vinschen wrote: >>> Hi Алексей, >>> >>> On Jun 8 01:56, Алексей Павлов wrote: >>>> 2013/6/7 Corinna Vinschen wrote: >>>>> A final note: I'm not opposing the fork. Under the GPL it's your >>>>> perfect right to do so, as long as you adhere to the license >>>>> requirements. But that doesn't mean I have to understand it. If the >>>>> DLL and the tools are exactly the same and only differ by name, then, >>>>> what's the point? Wouldn't it make more sense to work with us on the >>>>> Cygwin project instead? >>>>> >>>> Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64 >>>> IRC. It would be more right way I think but I think you don't interesting >>>> in it. I'm right? That is why I create fork of Cygwin. But if it possible >>>> to support MSYS2 mode in Cygwin sources I think all be happy to not create >>>> many forks an so on. >>> >>> The problem is this. So far I'm wondering what MSYS2 is about. >> >> MSYS is about mixing W32 tools (mingw-gcc, binutils) headers and >> libraries with *nixy (or cygwinny, if you prefer) buildtools and >> scripts, with the aim of building W32 libraries and applications. >> >> In Cygwin (or when running a real GNU system) you have to use a >> cross-compiler to build W32 binaries. >> In MSYS you don't have to. That's it. > > And why exactly is that a problem? The cross compiler is creating > the exact same code as a native-like compile with the same version. Cross-compiling is somewhat more tricky. Also do remember that MSYS1 is rather old, cross-compiling was even trickier back then. And Cygwin had - -mno-cygwin for that purpose back then too.
AFAIU, it's also tricky to run testsuite when cross-compiling. >> it should be obvious that crude >> symlink-by-copying is necessary to satisfy W32 tools, which cannot use >> cygwin symlinks or Windows .lnk files. > > Not really. If you need a copy, call cp. That's what it is for. > Faking symlinks by copying is just bad. So you create a symlink by > copying. Next you change the original. The consumers of the symlink > will never see this change. This is just... bad. Indeed, users are able to call cp instead of ln. Buildscripts can't. Buildscripts (which mostly means autotools) are written with the assumption that they will be run on a POSIX system, and thus MSYS has to provide POSIX tools. Just as Cygwin does. Except that Cygwin goes all the way down to the toolchain and compiles Cygwin programs, while MSYS stops early, only providing tools (i.e. things that are only used at build-time), and only those tools that can't be feasibly ported to W32 (i.e. pkg-config and gettext are ported, bison and bash are not; libtool is a borderline case - is a shell script, but it is also very W32-aware). I do understand that Cygwin improved a lot since MSYS1 fork, and that cross-compiling also moved on, so cross-compiling from Cygwin is not as scary as it was years ago (i hope it isn't; i don't use Cygwin, and i don't cross-compile on my Debian machine these days, so that's all just speculation on my part). Still, i'm not convinced that Cygwin is the universal, all-purpose tool that you seem to think it is (SquarePegRoundCygwin). - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRtx1xAAoJEOs4Jb6SI2CwWr0H/2gNYeqKZRzZz19yhDiMh6oT JMxIILyuGQ6JcSVQHK3JwAERdhTg7JumShehLaqd2diUOfxjbWvr7xXH8uuQST3g rcPIxQPMG5uTnJuSHuK3j9N2hDGKrpj3KgW+PZOix29hRJkQTnwi/vYs3cYHycv/ RgU0Qe/XbfuchYIEcBIAmgS6NNko2Cnmb2iHBEzTNsIpYdppxxbVorgGO822rzji okv4fqP9hLmS250zWIkhXgfsA/qrhMStItFje2e0MYUtqJNiANWrjgutGWSfx5Dx DENJBTd5GoKWdvjNxzvzA/G++JfRVNNAINnWHE9hSkKRcO7ApENYcHsyX2ma9Lo= =I1A8 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
