Msys，msys2和 msysgit 是如何相互关联的？

我一直在寻找，但我无法找到这3个版本的 MSYS 发生了什么完整的描述。(完全有可能我只是不知道要找什么。)我确实理解 MSYS 是 Linux 工具的一个最小端口，用于支持使用 MinGW 进行开发，但我不清楚这三个工具之间的关系，也不清楚开发/维护它们的团队之间的关系。

需要处理的特定问题:

  • 哪些正在积极开发? (特别是 MSYS 死了，MSYS2活了吗?)
  • 维护它们的团队之间是什么关系? (特别是 MSYS 团队是否创建了 MSYS2?)
  • 是 msysgit 只使用其中一个，还是他们有自己的 MSYS 分支？
  • 这些东西有相互兼容的吗？
  • 对于这些特定版本的 Windows，是否存在兼容性问题？
  • 其中一个提供了比另一个更重要的特性吗？
44677 次浏览
小开
最佳答案

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

虽然 MSYS 没有消亡，但我认为它看起来也不太健康。这是一个由 MinGW 团队多年前作为 一把 Cygwin 的叉子启动的项目，从来没有跟上 Cygwin 的步伐。

Msysgit 是带有一些自定义补丁、旧版本的 Bash 和 Perl 以及 Git 的本地端口的 一个稍微老版本的 MSYS 的分支。

MSYS2是 Mingw-build 团队的 Alexey Pavlov 发起的一个项目(他们是 MinGW-w64工具链的官方包装人员) ，作为 Cygwin 最近的一个分支，密切跟踪最新的 Cygwin，以便它不会过时。阿列克谢前进移植了旧的 MSYS 补丁，并添加了他自己的一些。

除了提供必要的 Unix 工具来编译本地软件(MSYS 的既定目标) ，我们还从 Arch Linux移植了 吃豆人包管理器。Pacman 不仅仅是管理二进制包(尽管它在这方面做得很好)。它有一个名为 makepkg 的软件构建基础设施，允许创建构建软件的配方(PKGBUILD 和补丁文件)。

恕我直言，Pacman 的采用极大地改变了 Windows 上的开源开发。每个人都可以用自己定制的 shell 脚本来以大杂烩、不兼容的方式构建软件，而软件包现在可以依赖于其他软件包，PKGBUILD 文件和相关补丁可以用作构建新 PKGBUILD 的参考。它与 Linux 系统非常接近(本地的) Windows 系统(特别是 Arch Linux) ，并且允许简单地更新所有安装的软件包。

我们以 WindowsXPSP3为最低目标，同时支持32位和64位 Windows。我们希望你们不要把 MSYS2和 msys 或者 msysgit 混在一起。Pacman 用于管理整个系统，因此，来自其他系统的文件将导致冲突。

我们还尝试将补丁上游到我们构建的项目中，并积极地从其他开源项目中征集贡献。我们希望别人觉得和我们一起工作很容易。

我们的主要网站是在 SourceForge上，它包含链接到我们的 PKGBUILD 知识库。我们也有一个更友好的用户在 GitHub安装站点。

如果你想了解更多信息，欢迎加入我们的 IRC (oftc # msys2)。

小开

Git 2.8(2016年3月)包含了一个非常详细的提交，解释了 msys2对于 在2015年初取代了 msysgit的新 窗户机器人的重要性。

见 提交 df5218b(2016年1月13日) by 约翰内斯 · 辛德林(dscho)。
(由 朱尼奥 · C · 哈马诺 gitster在 提交116a866合并，2016年1月29日)

在很长一段时间里，Git For Windows 落后于 Git 的2.x 版本，因为 Git For Windows 开发者希望让这个巨大的飞跃与从 MSys 到 MSys2的急需的飞跃同时发生。

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

为了支持这些脚本，Git for Windows 必须提供一个最小的 POSIX 模拟层，在 中引入 Bash 和 Perl，当 Git for Windows 在2007年8月开始时，这个开发者决定使用 微软系统服务公司，一个简化版的 Cygwin。
因此，该项目的最初名称是“ msysGit”(遗憾的是，这引起了 很多的混乱，因为很少有 Windows 用户知道 MSys，甚至更少的关心)。

为了编译用于 Windows 的 Git 的 C 代码，也使用了 MSys: 它运动 GNU C 编译器的两个版本:

  • 一个隐式链接到 POSIX 仿真层,
  • 另一个目标是普通的 Win32API (带有一些方便的函数)。

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

不过，这种对 MSys 的依赖也带来了挑战:

  • 我们对 MSys 运行时的一些更改(对于更好地支持 Windows 下的 Git 是必需的)在上游不被接受，所以我们必须维护自己的 叉子。
  • 此外，MSys 运行时没有进一步开发来支持 UTF-8或64位，除了在很久以后(mingw-get被引入时)才缺乏一个包管理系统，MSys/MinGW 项目提供的许多包落后于各自的源代码版本，特别是 Bash 和 OpenSSL。

有一段时间，Git For Windows 项目试图通过构建这些软件包的更新版本来纠正这种情况，但是这种情况很快就变得站不住脚，尤其是像 Heart〉 bug 这样的问题需要迅速采取行动，而这与进一步开发 Git For Windows 毫无关系。

令人高兴的是，与此同时，MSys2项目(https://msys2.github.io/) 并被选为 Windows 2.x Git 的基础。
就像 MSys 一样，msys2是一个精简版的 Cygwin，但它确实是 主动更新 Cygwin 的源代码 . < br/> 因此，它已经在内部支持 Unicode，并且还提供了自 Git for Windows 项目开始以来我们一直渴望的64位支持。

MSys2还从 Arch Linux 移植了 Pacman 软件包管理系统 并且大量使用它 用户习惯于从 yum或 apt-get，以及哪些 MacOSX 用户是 用于从家酿或 MacPorts，或 BSD 用户从端口系统, 到 MSys2: 一个简单的 pacman -Syu将更新所有安装的软件包到 目前最新的版本。

MSys2也是 非常活动的，通常提供包更新 每周多次。

它仍然需要两个月的努力才能把一切都带到一个国家 Git 的测试套件通过了测试，距离第一个正式测试还有很多个月吗 针对 Windows 2.x 的 Git 已经发布，还有几个补丁等待发布 他们提交给各自的上游项目。 然而没有 MSys2, 用于 Windows 的 Git 的现代化根本不会发生

这个提交为支持基于 MSys2的 Git 构建奠定了基础。

在评论 中，这个问题是在2016年1月提出的:

既然 Git for Windows 已经基于 MSYS2，那么不依赖于仿真层的二进制文件是否已经作为 MSYS2包提供？

雷 · 唐纳利(Ray Donnelly)当时回答说:

我们还没有完全合并，不过我们正在努力。

但是... Madz 指出在2017年初，这项努力没有成功。
参见:

问题是，我不能及时贡献将导致新的 msys2运行时的更改。
不过，这并不是一个大问题: 我只是让 Git 的 Windows 分支无限期地运行下去。

因此 wiki 现在提到(2018) :

Git for Windows 为 msys2运行时创建了一些没有发送到上游的补丁。(这已经计划好了，但是在第284期中已经确定这可能不会发生。)
这意味着您必须为 Windows 自定义的 msys2运行时安装 Git，以便在 MSYS2中拥有一个完全可以工作的 Git。

注意，自 犯下 aeb582a9(Git 2.22，Q22019)以来，Git for Windows 项目开始了基于 Cygwin v3.x 的 MSYS2运行时版本的升级过程。

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

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

这有非常显著的后果，$(uname -r)不再 报告一个以“2”开头的版本，而一个以“3”开头的版本。

这破坏了我们的构建，因为 Df5218b(config.mak.uname: 支持 MSys2, 2016-01-13，Git v2.8.0-rc0)只是没有期望 uname -r报告的版本依赖于底层的 Cygwin 版本: 它期望报告的版本 版本，以配合「 MSYS2」中的「2」。

因此，让我们反转该测试用例来测试 任何事，而不是以“1”开头的版本(对于 MSys)。
即使 Cygwin 最终发布了314.272.65536这样的版本，这也应该可以保护我们的未来。

Git 2.22(2019年第二季度)将针对 MSYS2运行时 v3.x 系列的更新进行测试。

见 犯罪(2019年5月7日) by 约翰内斯 · 辛德林(dscho)。
(由 朱尼奥 · C · 哈马诺 gitster于2019年5月19日在 犯罪合并)

t6500(mingw): 使用 shell 的 Windows PID

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

在升级到 MSYS2运行时 v3.x 之后，这个影子进程不能 不再通过 OpenProcess()访问，因此 t6500思想 在 gc.pid中引用的进程(不是 实际上在这个上下文中是一个真正的 gc进程，但是当前的 shell)没有 存在的时间更长。

让我们通过确保写入 WindowsPID 来修复这个问题 这个测试脚本中的 gc.pid，以便 git.exe能够理解 这个过程确实仍然存在。

Git 2.37.3(Q32022)通过有条件地允许在 Windows 上构建 Python 解释器，演示了如何使用 msys2:

见 犯下2f0623a，提交7934c74，提交49d279f(2022年7月29日) by 约翰内斯 · 辛德林(dscho)。
(由 朱尼奥 · C · 哈马诺 gitster于2022年8月8日在 提交8dfa09f合并)

删除不需要的 NO_CURL指令

签名: Johannes Schindelin

在 Df5218b(“ config.mak.uname: support MS2”，2016-01-13，Git v2.8.0-rc0—— 第四批中列出的 合并)中，我们介绍了在基于 MSYS2的当时全新的 Git for Windows v2.x 构建环境中为 Windows 构建 Git 的支持。

为了做到这一点，我们将非 msysGit 部分(针对 MSys1的部分)分成两部分，而不是与 MSys1共享 NO_CURL = YesPlease设置，我们用空值覆盖了 MSYS2的设置，因为我们非常想用 Libcurl为 Windows 构建 Git。

但这是没有必要的: 我们从来没有事先设置该变量，因此没有必要覆盖它。

我们把那条不必要的线移开吧。

小开

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

Compare Cygwin, msys, msys2, MinGW, git-for-windows, msysGit

摆弄 美人鱼中的完全图定义。


提交答案