From: Alexpux <al...@gm...> - 2013-06-12 11:53:30
|
-- Alexpux Отправлено с помощью Sparrow (http://www.sparrowmailapp.com/?sig) среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал: > 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. > This is changes in Cygwin dll not in bash. See changes in path.cc, spawn.cc and new files msys.cc and is msys.cc > > 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. Cygwin dll function uname changes > > 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. Yes it is bash changes and they also can be integrated in Cygwin bash I think > > 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) > > Yes it dangerous but native symlinks work need elevated shell and OS Vista+ > > 5. Add "-W" option to bash.exe's pwd command for compatibility with old > > MSYS. > > > > > Bash again, the underlying Cygwin DLL is not affected. You are right > > 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 > > thanks for it! > > 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. > Not very critical for me because it can be resolved > > 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 > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > |