Hi Алексей, On Jun 11 21:10, Алексей Павлов wrote: > Cygwin and MSYS have significantly different goals (even if MSYS is > entirely based on Cygwin). > > My understanding is that MSYS is the minimal shell required to run > autotools and get sources from internet from different repositories.
I'm again puzzled as to the mixup between the underlying POSIX DLL called Cygwin/MSYS2, and the full distro (The DLL plus all tools) called Cygwin/MSYS2. I'm concerned about forking the Cygwin DLL. I have no problems at all if you create a distro called MSYS2 centered around the upstream Cygwin DLL. > MSYS is about porting Unix programs to Windows without having a Posix > emulation layer, and then (hopefully!) getting those changes up-streamed. But Cygwin/MSYS2, the DLL *is* a POSIX layer. You can call it a parrot, and it's still a POSIX layer. > Typically, on MSYS, the executables that are run want to be native Win32 > where-as on Cygwin they want to be Posix and this will always be the case > and a problem. Why? Cygwin (the DLL) never refused to run native applications. > MSYS includes the following changes to Cygwin to support using native Win32 > programs: > 1. Automatic path mangling of command line arguments and environment > variables to Win32 form on the fly for Win32 applications inside bash.exe That's a bash change which does not affect the underlying Cygwin/MSYS DLL. > 2. Ability to change OSNAME with an environment variable (MSYSTEM) to > change it between MSYS and MINGW32 (so people can add to or fix MSYS > programs should they need to). Ditto. > 3. Conversion of output of native Win32 application output from Windows > line endings to Posix line endings - removing trailing '\r' symbol - in > bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as expected. Ditto. > 4. Replaced Cygwin symlinks with copying (we can investigate an option for > mklink symlinks on Vista and above but this is a topic for discussion - > MSYS compliant software tend to work around most ln-as-cp issues when > possible anyway). I said my share about what I think of copying files when the application expects to get a symlink. It's wrong. It's dangerous. You still have the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or CYGWIN=winsymlinks:nativestrict options available when using Cygwin unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html) > 5. Add "-W" option to bash.exe's pwd command for compatibility with old > MSYS. Bash again, the underlying Cygwin DLL is not affected. > 6. Perhaps remove /cygdrive prefix to simply typing paths. Mostly this is > to retain compatibility with MSYS-enabled software that makes assumptions > about /c/ being equivalent to C:/ It's not necessary at all to change the Cygwin/MSYS2 DLL to make this happen. Just add this to /etc/fstab: none / cygdrive binary,posix=0,user 0 0 Stop all Cygwin processes, login to your bash and try this: $ cd /c $ ls $Recycle.Bin Documents and Settings ProgramData System Volume Information bootmgr pagefile.sys Python32 Users BOOTNXT PerfLogs rhcygwin Windows cygwin Program Files swapfile.sys cygwin64 Program Files (x86) Symbols > 7. Minor changes to other userland programs (such as Perl so it reports > msys as $^O) which again helps to retain compatibility. Again, some tool, doesn't affect the Cygwin DLL. > The reality is that MSYS exists and it's really old and getting in the way > of developers, and MSYS2 is needed to replace this. I'm surprised therefore > at the negative reaction, but really hope that MSYS2 can be viewed as a > complimentary off-shot from Cygwin (even *hopefully* by the Cygwin > developers!). I'm not negative. I'm just defending the integrity of the Cygwin DLL. Again, I'm perfectly happy if you provide an MSYS2 distro containing special tools, like a tweaked bash and an entire, Mingw-centric toolchain arrangement, as long as you keep the underlying Cygwin DLL intact as provided upstream. Also, don't change the name of the DLL and the target name of the toolchain ({i686/x86_64}-pc-cygwin). Everyone would have an advantage of this: - There would be only one source of the underlying POSIX-providing DLL. Central repository, only one source to care about, no merging and tweaking hassle. - The DLL name stays intact, thus every tool built in and for the MSYS2 environment would run in a Cygwin distro environment as well. - The toolchain name stays intact. You can just grab the latest gcc and binutils sources and build them for the upstream supported ${arch}-pc-cygwin target and it would create files running in both environments. - While the normal Mingw/MSYS2 user would not have to look into the Cygwin distro since the MSYS2 distro provides what he or she needs, the more demanding user of MSYS2 would have free access to all tools provided by the Cygwin distro with thousands of tools and applications, not to mention a fully function X server with X clients. That's all I'm trying to say. I don't see a good reason to change the Cygwin DLL. Use it as is and build your Mingw-targeting environment around it. I'm here to help if something doesn't work out as you need it. Maybe we find another, working solution, without having to fork Cygwin. Thanks, 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
