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
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.
On Tue, Jun 11, 2013 at 12:43 PM, LRN <[email protected]> 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.
>
> > Granted, right now MSYS2 adds code which is entirely unacceptable for
> > Cygwin. For instance the symlink(2) function *copying* files, even
> > recursively if the target is a directory. I don't grok the reason for
> > this.
> >
> > So here's a user or script innocently calling
> >
> > ln -s /cygdrive/c/Windows /
> >
> > which is something I do often to have easier access to the Windows
> > directory for certain tasks. But I definitely don't want a copy of the
> > Windows directory. If it's about compatibility with native tools, the
> > change still doesn't makes sense.
> >
> > - Either it's Cygwin/MSYS2 tools needing the symlink, then a Cygwin
> > symlinks works fine,
> >
> > - or you need a copy of a certain subtree, then you should have called
> > cp, rather than ln -s,
> >
> > - or you need a Windows symlink, then you should have created a
> > native symlink using the new Cygwin capability to create native
> > symlinks using the CYGWIN=winsymlinks:native{strict} setting.
> >
> > The latter would be much more feasible as default setting, while on old
> > pre-Vista systems, it would be much more feasible to fail gracefully, or
> > to use Cygwin's method to create a Windows .lnk file instead.
>
> Now that you know what MSYS is about, it should be obvious that crude
> symlink-by-copying is necessary to satisfy W32 tools, which cannot use
> cygwin symlinks or Windows .lnk files.
> Windows symlinks (when using NT 6 and newer) are fine (well, they are
> not POSIXly, but they may turn out to be better than dumb copying (for
> the purpose of using them when building software), i'll try to test that
> later), MSYS1 had no way of creating them, and thus this was not an
> option. Now it is an option, and maybe a good default too.
>
> - --
> O< ascii ribbon - stop html email! - www.asciiribbon.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
>
> iQEcBAEBAgAGBQJRtw15AAoJEOs4Jb6SI2CwJbMIALMwC7zDIHRjRpKlFX/Zuk6k
> kt6s1/mstnSK6+WJdN5H2BxO2bXfxSBZDSiiwLXxe0UmTkdqFejQoO0JXiUiGwdM
> ne8KBy4EAdL4hxiEfhyiJhmAdZoEXktJMrlCX5AdFP22EueSc97D1hy12zM8EiMr
> rPHVe/0hL5sJ2Yk9LE0eAghMwEMIrnicAIWuyi9hpMG9U3IFAUf6GFLkV8ocT3Ga
> LO+rDDhuLclwpAIJ7p1FX4BwIgnzbCyYxZ9u8rlRB16cntIaJkzwNuxLmYKRjlra
> ZqiZKxayenMQBhiF/Q1OMjOOCBdi4DGoppsDffVgnGvLGA6fQG7ZDcIW5vCZqbI=
> =iQw0
> -----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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
------------------------------------------------------------------------------
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
