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.
If you really want that badly, you could get this by not installing
the Cygwin gcc4 package but rather installing matching hardlinks or
symlinks in the /bin directory. This hardly explains the requirment
for a fork.
> > [...]
> > - 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,
You're not telling me that *this* is what MSYS2 is about, right?
Not seriously.
> 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.
> 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.
And then, if you;re using them as default, the question returns. Why
not use Cygwin with this option rather than the fork? ou can simply set
up your default environment with the CYGWIN=winsymlinks:native{strict}
option and you're all set.
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
