msys，msys2和msysgit如何相互关联？

162

我一直在搜索，但是找不到这3个版本的MSYS的完整描述。（完全有可能我只是不知道要寻找什么。）我确实知道MSYS是Linux工具的最小端口，可以支持使用MinGW进行开发，但是我不清楚这三个工具之间的关系。开发/维护他们的团队。

要解决的特殊问题：

  • 哪些正在积极开发中？（特别是，MSYS是否已失效而MSYS2是否处于活动状态？）
  • 维持他们的团体之间有什么关系？（特别是，MSYS团队是否创建了MSYS2？）
  • msysgit是否仅使用其他之一，或者它们具有自己的MSYS分支？
  • 这些相互兼容吗？
  • 这些特定版本的Windows是否存在任何兼容性问题？
  • 一个提供其他功能吗？
msys  msys2 
— jpmc26
source
8
@JamesJohnston在编写此问题之前，我（现在是）理解MSYS和MinGW是作为Cygwin的竞争对手而创建的，因为Cygwin（至少以前；我不确定其当前状态）迫使任何新代码都通过一个相当不好的兼容性层，而不是直接调用Windows API。因此，我一直将MSYS及其亲戚视为比Cygwin轻的系统，所以我对Cygwin的当前状态不感兴趣。不过，如果您有兴趣，这可能是一个很好的跟进问题；随便问一问是否可以将其表达为主题。
— jpmc26 2015年
4
直到昨天开始深入挖掘我之前，我也一直有这种印象。@Ray Donnelly指出，您提到的MSYS的所有三个版本都是Cygwin的分支。因此从这个意义上讲，它们都是“ Cygwin”-这个问题实际上是关于Cygwin及其分支的。正如Ray所指出的，MSYS似乎注定了失败。我自己检查了MSYS代码。它已经过时了，甚至缺乏对共享内存的基本同步。维护人员只是跟不上上游，也从未获得上游Cygwin所获得的共享内存修复程序。
— 詹姆斯·约翰斯顿
9
@JamesJohnston我想你误会了。我的观点是，Cygwin不支持（不支持）没有兼容性层的新二进制文件的构建。MSYS和亲戚通过MinGW进行。因此，尽管我很清楚所有人都起源于Cygwin，但我对Cygwin并不感兴趣。由于我对Cygwin不感兴趣，因此提出这个问题没有意义。这个问题也主要集中在分叉本身的历史，原因以及它的一些基本后果上。当试图在MSYS的不同版本之间进行选择时，Cygwin的历史并不重要。
— jpmc26 2015年
1
我不明白的是为什么MSYS2开发人员和Cygwin开发人员无法达成协议并退出争论，所以我们可以停止使用这些愚蠢的分支。Cygwin很少受到关注，但是至少有Red Hat的有薪员工正在从事这项工作。叉子甚至都没有。我在去年的Cygwin邮件列表中发现有关使MSYS2只是Cygwin的一个钩子DLL的讨论，这样MSYS2不必派生整个Cygwin DLL。显然，这些讨论并没有走多远。当MSYS2现在充满活力时，如果MSYS2志愿者停止对其进行更新，我可以预见它会像MSYS一样停滞不前
— James Johnston
1
@JamesJohnston我认为您可能可以在Ray提到的IRC频道上对您的问题获得更好的答案。这个评论链变得相当长，并且偏离了主题。
— jpmc26 2015年

Answers:

178

免责声明：我是MSYS2开发人员

虽然MSYS还没死，但我也想说它也不是很健康。这是MinGW团队多年前作为Cygwin的分支发起的一个项目，但从未与Cygwin保持同步。

msysgit是MSYS较旧版本的分支带有一些自定义补丁，Bash和Perl的旧版本以及Git的本机端口。

MSYS2是由mingw-builds团队的Alexey Pavlov（他是MinGW-w64工具链的官方打包程序）启动的一个项目，它是Cygwin的最新分支，它密切跟踪最新的Cygwin，以确保它不会过时。Alexey向前移植了旧的MSYS补丁，并添加了一些自己的补丁。

除了提供编译本地软件所需的Unix工具（MSYS的既定目标）外，我们还从Arch Linux移植了Pacman软件包管理器。Pacman不仅仅是管理二进制软件包（尽管它做得很好）。它具有一个称为makepkg的软件构建基础结构，该基础结构允许创建用于构建软件的配方（PKGBUILD和补丁文件）。

恕我直言，Pacman的采用大大改变了Windows上的开源开发。软件包现在可以依赖其他软件包，而PKGBUILD文件和关联的补丁程序可以用作构建新的PKGBUILD的参考，而不是每个人都以自己的定制shell脚本为首，以不兼容的方式构建软件。它（一个本机）Windows可以（特别是Arch Linux）所能接近的Linux系统，并且可以轻松更新所有已安装的软件包。

我们以Windows XP SP3为最低目标，并支持32位和64位Windows。我们将要求您不要将MSYS2与msys或msysgit混合使用。Pacman用于管理整个系统，因此，来自其他系统的文件将引起冲突。

我们还尝试将补丁打入我们构建的项目的上游，并积极寻求其他开源项目的贡献。我们希望其他人发现与我们合作很容易。

我们的主要网站位于SourceForge上，它包含指向PKGBUILD存储库的链接。我们还在GitHub上有一个更加用户友好的安装程序站点。

如果您需要更多信息，请随时加入我们的IRC（oftc＃msys2）。

— 雷·唐纳利
source
6
可以使用msys2来构建和运行git（即替换msysgit）。
— eckes
10
MSYS2有一个git包。它是MSYS2版本，而不是本机版本。要安装git，请执行以下操作：pacman -S git ..我们的MINGW-packages存储库中还有msysgit的进行中端口。
— 雷·唐纳利
16
不，我们的MSYS2 git功能完善且没有黑客攻击。我们在其他软件包的开发中广泛使用了它。有人担心MSYS2（因为它是Cygwin的分支）增加了文件操作的大量开销，并且由于git的文件操作繁重，因此本机git会更快。证明或反对这一点的方法是同时拥有和基准化它们，这就是我们将要做的。我对这里的术语要小心，因为我对msysgit的引用涉及两个不同的东西，即具有本机Windows git的msys-fork和本机Windows git。这里我指的是后者！
— Ray Donnelly 2014年
7
@eckes我只是想说我已经在git上使用MSYS2了几个月了。MSYS2有几个粗糙的领域（什么软件没有？），但是我一直很高兴使用它。它们都与git本身无关。
— jpmc26 2014年
7
msys2的承诺符合我的期望。保持良好的工作，@ RayDonnelly
— bvj 2015年
72

Git的2.8（2016年3月），包括一个非常详细的承诺这解释msys2的新的重要性混帐的窗口，其取代msysgit在2015年初。

参见Johannes Schindelin（）的commit df5218b（2016年1月13日）。（由Junio C Hamano合并--在commit 116a866中，2016年1月29日）dscho
gitster

长期以来，Windows的Git落后于Git的2.x版本，因为Windows的Git开发人员希望让这一大跃进与从MSys到MSys2的急需的转变同时发生。

要理解为什么这是一个大问题，需要注意的是，Git的许多部分不是用可移植的C编写的，而是Git依赖于POSIX shell和Perl来提供的。

为了支持脚本，Git for Windows必须附带一个最小的POSIX仿真层，并插入Bash和Perl，并且当Git for Windows于2007年8月开始工作时，该开发人员决定使用MSys（精简版的Cygwin）。
因此，该项目的原始名称为“ msysGit”（可悲的是，由于很少有Windows用户了解MSys，甚至引起了越来越少的关注，这引起了很多混乱）。

为了编译用于Windows的Git的C代码，还使用了MSys：它具有两个版本的GNU C编译器：

  • 一个隐式链接到POSIX仿真层的程序，
  • 另一个针对普通的Win32 API（带有一些便捷功能）。

Git for Windows的可执行文件是使用后者构建的，因此它们实际上只是Win32程序。为了区分不需要POSIX仿真层的可执行文件，当前者称为MSys可执行文件时，后者称为MinGW（Windows的最小GNU）。

但是，对MSys的依赖也带来了挑战：

  • 我们对MSys运行时所做的某些更改（更好地支持Windows的Git所必需的）未在上游接受，因此我们必须维护自己的fork。
  • 此外，MSys运行时并未得到进一步开发以支持UTF-8或64位，并且除了缺少软件包管理系统（直到后来）（mingw-get引入时）之外，MSys / MinGW项目提供的许多软件包都落后于各自源代码版本，尤其是Bash和OpenSSL。

有一段时间，Git for Windows项目试图通过尝试构建这些软件包的较新版本来纠正这种情况，但是这种情况很快变得难以为继，尤其是诸如Heartbleed错误之类的问题，需要迅速采取行动，而这与开发Git无关。 Windows进一步。

令人高兴的是，与此同时，出现了MSys2项目（https://msys2.github.io/），并被选为Windows 2.x Git的基础。
就像MSys一样，MSys2是Cygwin的精简版本，但是它积极地与Cygwin的源代码保持同步。
因此，它已经在内部支持Unicode，并且还提供了自Git for Windows项目开始以来我们所渴望的64位支持。

MSys2还从Arch Linux移植了Pacman软件包管理系统，并大量使用它。这为使用Linux yum或Linux的用户apt-get，以及使用Homebrew或MacPorts的MacOSX用户或使用Ports系统的BSD用户提供了相同的便利：pacman -Syu将所有已安装的软件包更新为最新版本目前可用。

MSys2也非常活跃，通常每周提供多次软件包更新。

它仍然需要两个月的时间才能使所有内容都通过Git的测试套件通过，还需要几个月的时间，直到第一个正式的Windows 2.x正式版Git发布，并且还有两个补丁仍在等待提交给各自的上游项目。 。但是，如果没有MSys2，Windows的Git现代化根本就不会发生。

这一承诺为支持基于MSys2的Git构建奠定了基础。

在评论中，于2016年1月提出问题：

由于Windows的Git已经基于MSYS2，因此是否将不依赖于仿真层的二进制文件作为MSYS2软件包提供了？

雷·唐纳利当时回答：

我们尚未完全合并，不。我们正在努力。

但是... madz 指出，在2017年初，这种努力并未奏效。
看到：

问题是我无法做出及时导致新的msys2-runtime的更改。
不过，这不是什么大问题：我将让Git for Windows的fork无限期地运行。

因此，Wiki现在提到（2018）：

Git for Windows为msys2-runtime创建了一些尚未向上游发送的补丁。（这已经计划好了，但是在问题＃284中确定可能不会发生。）
这意味着您必须安装Git for Windows定制的msys2-runtime，才能在MSYS2中具有完全正常的git。

请注意，由于提交了aeb582a9（Git 2.22,2019年第二季度），因此Git for Windows项目启动了基于Cygwin v3.x的MSYS2运行时版本的升级过程。

mingw：允许使用MSYS2运行时v3.x进行构建

最近，用于Windows的Git项目开始了基于Cygwin v3.x的MSYS2运行时版本的升级过程。

这具有非常显着的结果，即$(uname -r)不再报告以“ 2”开头的版本，而是报告以“ 3”开头的版本。

由于df5218b（config.mak.uname：support MSys2，2016-01-13，Git v2.8.0-rc0）根本不希望报告的版本uname -r依赖于基本的Cygwin版本，因此这会中断我们的构建：它希望报告的版本与“ “ MSYS2”中的“ 2”。

因此，让我们反转该测试用例以测试除以“ 1”开头的版本（对于MSys）以外的其他任何内容。
即使Cygwin最终发布了314.272.65536之类的版本，这也应该为我们的未来提供保障。

Git 2.22（Q2 2019）将针对MSYS2运行时v3.x系列的更新进行未来测试。

参见Johannes Schindelin（）的commit c871fbe（2019年5月7日）。（由Junio C Hamano合并--在commit b20b8fe中，2019年5月19日）dscho
gitster

t6500(mingw)：使用外壳的Windows PID

在Windows的Git中，我们使用了MSYS2 Bash，该继承自Cygwin的POSIX仿真层的非标准PID模型：每个MSYS2进程都有一个常规的Windows PID，此外，它还有一个MSYS2 PID（与模拟的影子进程相对应） Unix风格的信号处理）。

随着MSYS2运行时v3.x的升级，不再可以访问此影子进程OpenProcess()，因此t6500错误地认为所引用的进程gc.pid（gc在此情况下实际上不是真正的进程，而是当前的shell）不再存在存在。

让我们通过确保gc.pid在此测试脚本中写入Windows PID来解决此问题， 以便git.exe能够理解该进程确实仍然存在。

— 冯
source
1
这就提出了一个非常有趣的问题：由于Windows的Git已经基于MSYS2，因此是否将不依赖于仿真层的二进制文件作为MSYS2软件包提供了？上面的@RayDonnelly提到MSYS2团队有兴趣创建这类二进制文件，以查看其性能差异如何。
— jpmc26 2016年
4
我们尚未完全合并，不。我们正在努力。
— Ray Donnelly
4
对此进行扩展。.暂时，到目前为止，MSYS2的git包仍链接到msys-2.0.dll，正在进行将MSYS2与Windows的Git合并的过程，一旦完成，我们希望删除git包因为msys-2.0.dll链接的软件包可以支持构建本机软件，因此它们本身并不是一个最终目标。
— Ray Donnelly
1
@RayDonnelly目前状态是什么？如果用MSYS2（软件包管理！）替换Windows版的Git，有什么缺点吗？
— Brecht Machiels '16
2
— Brecht Machiels '16
18

我对它们之间的联系的理解是

  • Cygwin在Windows顶部提供POSIX仿真
  • msys试图简化Cygwin，但自2010年起已过时
  • msysGit -允许的Git高达1.9.4在Windows上（可称为混帐的窗口-1.X），基于旧版本MSYS的。
  • msys2-简化的Cygwin，由它派生，具有msys的更改，并与Cygwin的功能保持同步，并与Pacman集成
  • MinGW-最初的MinGW，从2010年起废弃
  • MinGW-w64-与Windows更快更好地集成，无需POSIX
  • git-for-windows- 2.x-使用MinGW-64和MinGW-32在Windows下从2.X提供Git，并且在无法回退到msys2的情况下提供

比较Cygwin，msys，msys2，MinGW，git-for-windows，msysGit

在人鱼中用完整的图定义提琴。

— 兰考司汀
source
1
漂亮的图形。+1。不过，“ Git for Windows 1.0”确实是在尽力而为的基础上完成的：stackoverflow.com/a/1704687/6309（我在stackoverflow.com/a/50555740/6309中提到）
— VonC
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.