I wonder if it would be possible to have a plugin system to allow for the
behaviour changes we need to cygwin.dll, so msys.dll exists and only
handles those parts and cygwin.dll loads that as a plugin, if there's no
plugin specified then everything proceeds as 'normal cygwin'.
Would you be willing to consider something like this Corinna?
On Wed, Jun 12, 2013 at 12:50 PM, Alexpux <[email protected]> wrote:
>
>
> --
> 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
> [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
>
>
------------------------------------------------------------------------------
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
