Merge msys2 into cygwin

[mappu]

Hi,

Sorry if this is the wrong place for this, or if i am totally misguided.

Is there any hope that MSYS2 can be merged with cygwin? Can the mingw-w64 toolchains in cygwin do what MSYS2 does?

My simple use case seems that

• MSYS2/MSYS2 - /c/-style paths, can fopen() C:\ paths without dosfilewarning, depends on posix compatibility dll msys-2.0.dll
• Cygwin/gcc - /cygdrive/-style paths, can fopen() C:\-style paths with a dosfilewarning, depends on posix compatibility dll cygwin1.dll
• MSYS2/mingw-w64 - C:\ style paths, no posix compatibility dll
• Cygwin/mingw-w64 - C:\ style paths, no posix compatibility dll

The point of MSYS2 is to build windows packages, but it appears that mingw-w64 toolchain behaves similarly under both Cygwin and MSYS2, so I don't understand what the cause of the fork is that they need to be separated.. (pacman is surely a cooler package manager than cygwin's setup.exe gui, MSYS2 has some newer packages and more win32-targeted packages, but cygwin has more packages available for it's "mini os").

There was some mention of it in this old post https://github.com/JuliaLang/julia/issues/3640 ("I discuss with Cygwin developers about adding MSYS mode directly in Cygwin sources") but i couldn't easily find any more mention of the idea.

Regards mappu

[mingwandroid]

You seem to be trying to imply that at core, Cygwin and MSYS2 are exactly the same, i.e. cygwin1.dll and msys-2.0.dll are basically the same, is this correct?

[mappu]

Yes. Not exactly identical, otherwise there would be no need for a separate project. But MSYS2 is a fork of cygwin and msys-2.0.dll is a modified cygwin1.dll, right? The exported functions are largely the same, and the dlls do perform largely the same role.

I would appreciate some help understanding what the differences are, whether MSYS2's changes could potentially have been made within the Cygwin project, and what the roadmap is for any future relationships between the Cygwin and MSYS2 projects

(Consider this a documentation issue)

[Alexpux]

In the past we have discussion with Cygwin developers about merging MSYS functionality in Cygwin code. They don't want to do it and offered us variant about extending Cygwin DLL by preloading another DLL that will change Cygwin logic. Something like this: https://github.com/Alexpux/Cygwin/commit/4f756d6cc28179319ceccce01dd698de3f22c212 This is first dirty variant. But we don't have time and man power to try implement it as it need a lot of effort and maybe not work. If you want that MSYS functionality will be merged in Cygwin and you have such knowledges you can open discussion with Corinna on Cygwin ML and try implement this. Our team is very small and we don't want to spent time for it.

Main changes to Cygwin DLL that we do:

• Remove cygwin symlinks (as native applications doesn't understand them) and now instead symlink created copy of the file.
• Add mechanism of translating UNIX paths to Windows for native Windows applications when they are passed via arguments or environment.
• Many other small tweaks needed to properly work with native apps.

[mingwandroid]

@mappu

whether MSYS2's changes could potentially have been made within the Cygwin project

Potentially of course, since we forked it and added stuff. In reality, to do it in a way that Cygwin would accept, only through Cygwin having a working extension capability. Directly importing MSYS2 code into Cygwin would make Cygwin harder to maintain, and the Cygwin project is all about emulating POSIX, not interoperability with native Windows. Also, Christopher Faylor has left the Cygwin project which is a great shame as he was the most supportive of having this extension capability.

What the roadmap is for any future relationships between the Cygwin and MSYS2 projects

We will continue to re-sync with Cygwin regularly so that we don't get out of date like the original MSYS did. If you were willing to work on refactoring the MSYS2 changes through the nascent/stillborn Cygwin extension system then that'd be really cool.

Without wishing to downplay the importance of this, like Alexey, I've got far too many other things to do. This task needs someone willing to finish (start!) the work and also go through the upstreaming review process (do not underestimate how difficult that will be).

[goyalyashpal]

• earlier, i used to think like a typical person: unable to read/understand the issue & relying on the reviews that cygwin is sometimes slow - 'was a bit afraid of change.
• but now, after facing soooo many of softwares i wanna use not being available for windows, i feel the need to use cygwin too...
• and suddenly, most things written there start making sense to me, yeah, it will be indeed nice to not have multiple copies of same underlying stuff on my pc

It would be nice if people could just install one POSIX emulation layer and have everything available from there.

• so yay, more power to you in merging with cygwin. awesome thoughts for future direction, may u succeed.
• ref1: Devtopics/#merge-with-cygwin (here: archive)
• ref2: History (here: archive)
• ref3: supposedly the back-setting for this: [# 3012] : move build env closer to gywin