Как msys, msys2 и msysgit связаны друг с другом?

162

Я искал вокруг, но я не могу найти подробное описание того, что происходит с этими 3 версиями MSYS. (Вполне возможно, я просто не знаю, что искать.) Я понимаю, что MSYS - это минимальный порт инструментов Linux для поддержки разработки с использованием MinGW, но мне не ясны отношения между ними тремя или команды, которые разработали / поддерживают их.

Конкретные вопросы для решения:

  • Какие из них находятся в стадии активной разработки? (В частности, MSYS мертв, а MSYS2 активен?)
  • Каковы отношения между группами, которые их поддерживают? (В частности, команда MSYS создала MSYS2?)
  • Использует ли msysgit только один из них или у них есть своя ветвь MSYS?
  • Совместимы ли какие-либо из них друг с другом?
  • Есть ли какие-либо проблемы совместимости с конкретными версиями Windows для любого из них?
  • Предоставляет ли один основные функции над другим?
jpmc26
источник
8
@JamesJohnston До того, как написать этот вопрос, я понял (и понимаю), что MSYS и MinGW были созданы как конкурент Cygwin, потому что Cygwin (по крайней мере ранее; я не уверен в его текущем состоянии) заставлял проходить любой новый код довольно неэффективный уровень совместимости вместо непосредственного вызова API-интерфейсов Windows. Поэтому я всегда видел в MSYS и его родственниках более легкую систему веса, чем в Cygwin, поэтому меня не интересовал текущий статус Cygwin. Это может быть хорошим вопросом для продолжения, если вам интересно; не стесняйтесь спрашивать, можете ли вы сформулировать это по теме.
jpmc26
4
Я тоже был под этим впечатлением, пока вчера не начал копаться под одеялом. Все три версии MSYS, которые вы упомянули, являются вилками Cygwin, как отмечает @Ray Donnelly. Таким образом, в этом смысле все они "Cygwin" - и этот вопрос действительно о Cygwin и его вилках. Как указывает Рэй, похоже, что MSYS обречена. Я сам изучил код MSYS; он безнадежно устарел и не имеет даже базовой синхронизации над общей памятью. Сопровождающие просто не поспевали за апстримом и никогда не получали исправлений для разделяемой памяти, которые получил апстрим Cygwin.
Джеймс Джонстон
9
@JamesJohnston Я думаю, вы не поняли. Я хочу сказать, что Cygwin не поддерживает (не?) Создание новых двоичных файлов без уровня совместимости. MSYS и родственники делают через MinGW. Таким образом, я не заинтересован в Cygwin, хотя хорошо знаю, что все они имеют корни в Cygwin. Поскольку я не заинтересован в Cygwin, не было смысла спрашивать об этом. Этот вопрос также фокусируется в первую очередь на истории разветвления и его причинах, а также на некоторых элементарных последствиях этого. При попытке выбора между различными версиями MSYS история Cygwin не очень актуальна.
jpmc26
1
Чего я не понимаю, так это того, почему разработчики MSYS2 и Cygwin не могут прийти к соглашению и прекратить ссоры, чтобы мы могли перестать получать эти глупые вилки. Cygwin уделяет мало внимания, как минимум, но, по крайней мере, над ним работают оплачиваемые сотрудники Red Hat; вилы даже не понимают этого. В прошлом году в списке рассылки Cygwin я обнаружил, что MSYS2 просто является подключаемой DLL для Cygwin, так что MSYS2 не нужно было форкать всю Cygwin DLL; видимо, эти дискуссии не зашли далеко. Хотя у MSYS2 теперь есть энергия, я ожидаю, что она застынет как MSYS, если / когда волонтеры MSYS2 прекратят ее обновлять
Джеймс Джонстон,
1
@JamesJohnston Я думаю, вы сможете получить лучшие ответы на свои вопросы на IRC-канале, который Рэй упоминает в своем ответе. Эта цепочка комментариев становится довольно длинной и отклоняется от темы.
jpmc26

Ответы:

178

Отказ от ответственности: я разработчик MSYS2

Хотя MSYS не умер, я бы сказал, что он тоже не очень здоров. Это проект, начатый командой MinGW много лет назад как форк Cygwin, который никогда не отставал от Cygwin.

msysgit - это ветвь немного более старой версии MSYS с некоторыми пользовательскими исправлениями, старыми версиями Bash и Perl и собственным портом Git.

MSYS2 - это проект, начатый Алексеем Павловым из команды mingw-builds (которые являются официальными упаковщиками для наборов инструментов MinGW-w64) в качестве недавней развилки Cygwin, которая внимательно следит за последним Cygwin, чтобы он не устарел. Алексей вперёд перенес старые патчи MSYS и добавил несколько своих.

Помимо предоставления необходимых инструментов Unix для компиляции нативного программного обеспечения - заявленной цели MSYS - мы перенесли менеджер пакетов Pacman из Arch Linux . Pacman - это больше, чем просто управление бинарными пакетами (хотя он делает это очень хорошо). Он имеет инфраструктуру для создания программного обеспечения под названием makepkg, которая позволяет создавать рецепты (PKGBUILD и файлы патчей) для создания программного обеспечения.

ИМХО, принятие Pacman существенно меняет ситуацию для разработки с открытым исходным кодом на Windows. Вместо того, чтобы все взламывали свои собственные скрипты оболочки для создания программного обеспечения в виде мешковины, несовместимым способом, пакеты теперь могут зависеть от других пакетов, а файлы PKGBUILD и связанные с ними патчи могут использоваться в качестве ссылки для создания новых PKGBUILD. Она настолько близка к системе Linux, насколько может (родной) Windows (в частности, Arch Linux), и позволяет легко обновлять все установленные пакеты.

Мы нацелены как минимум на Windows XP SP3 и поддерживаем как 32-разрядную, так и 64-разрядную версию Windows. Мы просим вас никогда не смешивать MSYS2 с msys или msysgit. Pacman используется для управления всей системой, и поэтому файлы из других систем будут вызывать конфликты.

Мы также стараемся направлять наши патчи на проекты, которые мы создаем, и активно запрашиваем вклады от других проектов с открытым исходным кодом. Мы надеемся, что другим будет легко с нами работать.

Наш основной сайт находится на SourceForge и содержит ссылки на наши репозитории PKGBUILD. У нас также есть более удобный для пользователя сайт установщика на GitHub .

Присоединяйтесь к нам на IRC (oftc # msys2), если вам нужна дополнительная информация.

Рэй Доннелли
источник
6
Можно ли использовать msys2 для сборки и запуска git (т.е. заменить msysgit).
Eckes
10
MSYS2 имеет пакет git. Это версия MSYS2, в отличие от собственной версии. Для установки git: pacman -S git .. у нас также есть порт работы с msysgit в нашем хранилище MINGW-пакетов.
Рэй Доннелли
16
Нет, наш MSYS2 git не содержит хакерских функций. Мы широко используем его при разработке других пакетов. Существует опасение, что MSYS2 (так как это ветвь Cygwin) добавляет много накладных расходов к файловым операциям, а поскольку git требует больших операций с файлами, родной git будет быстрее. Способ доказать или опровергнуть это состоит в том, чтобы иметь и то, и другое, чтобы сравнить их, так что мы будем это делать Я должен быть осторожен с терминами здесь, так как мои ссылки на msysgit относятся к двум разным вещам: msys-fork с собственным git для Windows и также собственным git для Windows. Здесь я имею в виду последнее!
Рэй Доннелли
7
@eckes Я просто хочу сказать, что я использую MSYS2 для git уже несколько месяцев. У MSYS2 есть несколько грубых моментов (какое программное обеспечение нет?), Но я был очень счастлив, используя его. Ни один из них не был связан с самим мерзавцем.
jpmc26
7
Обещание msys2 оправдывает мои ожидания. Продолжайте в том же духе, @RayDonnelly
Bvj
73

Git 2.8 (март 2016 года) включает в себя очень подробный коммит, который объясняет важность msys2 для нового git-for-windows, который заменил msysgit в начале 2015 года .

Смотрите коммит df5218b (13 января 2016 г.) Йоханнеса Шинделина ( dscho) .
(Слиты Junio C Hamano - gitster- в фиксации 116a866 , 29 янв 2016 г.)

Долгое время Git для Windows отставал от выпусков Git 2.x, потому что разработчики Git для Windows хотели, чтобы этот большой скачок совпал с столь необходимым переходом от MSys к MSys2.

Чтобы понять, почему это такая большая проблема, необходимо отметить, что многие части Git написаны не на переносимом C, а вместо этого Git полагается на оболочку POSIX и Perl, которые будут доступны .

Для поддержки сценариев Git для Windows должен поставлять минимальный слой эмуляции POSIX с добавлением Bash и Perl , а когда в августе 2007 года началась работа над Git для Windows, этот разработчик решил использовать MSys, урезанную версию Cygwin .
Следовательно, первоначальное название проекта было «msysGit» (что, к сожалению, вызвало много путаницы, потому что мало пользователей Windows знают о MSys, и даже меньше заботятся).

Для компиляции кода C для Git для Windows также использовался MSys: он поддерживает две версии компилятора GNU C:

  • тот, который неявно связан с уровнем эмуляции POSIX,
  • и еще один, предназначенный для простого Win32 API (с несколькими добавленными вспомогательными функциями).

Исполняемые файлы Git для Windows создаются с использованием последних, и поэтому они на самом деле просто программы Win32. Чтобы отличить исполняемые файлы, требующие уровня эмуляции POSIX, от тех, которые этого не делают, последние называются MinGW (Minimal GNU для Windows), а первые называются исполняемыми файлами MSys .

Эта зависимость от MSys также вызывала проблемы:

  • некоторые из наших изменений в среде выполнения MSys, необходимые для лучшей поддержки Git для Windows, не были приняты в апстриме, поэтому нам пришлось поддерживать собственный форк.
  • Кроме того, среда выполнения MSys не получила дальнейшего развития для поддержки, например, UTF-8 или 64-разрядных, и, за исключением отсутствия системы управления пакетами до гораздо более позднего времени (когда она mingw-getбыла представлена), многие пакеты, предоставляемые проектом MSys / MinGW, отстают от соответствующих версии исходного кода, в частности Bash и OpenSSL.

Некоторое время проект Git для Windows пытался исправить ситуацию, пытаясь создать более новые версии этих пакетов, но ситуация быстро стала несостоятельной, особенно с такими проблемами, как ошибка Heartbleed, требующая быстрых действий, которые не имеют ничего общего с разработкой Git для Окна дальше.

К счастью, тем временем появился проект MSys2 ( https://msys2.github.io/ ), который был выбран в качестве основы для Git для Windows 2.x.
Как и MSys, MSys2 является урезанной версией Cygwin, но она активно обновляется с исходным кодом Cygwin .
Таким образом, он уже поддерживает внутреннюю Unicode, а также предлагает 64-битную поддержку, к которой мы стремились с начала проекта Git для Windows.

MSys2 также перенес систему управления пакетами Pacman из Arch Linux и активно использует ее . Это приносит то же удобство, к которому привыкли пользователи Linux из yumили или apt-get, и к которому привыкли пользователи MacOSX из Homebrew или MacPorts или пользователей BSD из системы портов, в MSys2: простое pacman -Syuобновит все установленные пакеты до самых последних версий доступен на данный момент.

MSys2 также очень активен, обычно предоставляет обновления пакетов несколько раз в неделю.

Потребовалось еще два месяца, чтобы привести все в состояние, в котором тестовый набор Git проходит, еще много месяцев, пока не был выпущен первый официальный Git для Windows 2.x, и пара патчей все еще ожидает их отправки в соответствующие апстрим-проекты. , Однако без MSys2 модернизация Git для Windows просто не состоялась бы .

Этот коммит закладывает основу для поддержки сборок Git на основе MSys2.


В комментариях вопрос был задан в январе 2016 года:

Поскольку Git для Windows уже основан на MSYS2, были ли двоичные файлы, не зависящие от уровня эмуляции, доступны в виде пакета MSYS2?

Рэй Доннелли ответил тогда:

Мы еще не полностью слились, нет. Мы работаем над этим, хотя.

Но ... Мадз отмечает, что в начале 2017 года эти усилия не увенчались успехом .
Видеть:

Проблема в том, что я не могу своевременно вносить изменения, которые приведут к новой среде msys2.
Не большая проблема, однако: я просто буду держать форк Git для Windows на неопределенный срок.

Поэтому вики упоминает сейчас (2018):

Git для Windows создал несколько исправлений для msys2-runtime, которые не были отправлены в апстрим. (Это было запланировано, но в выпуске № 284 было определено, что этого, скорее всего, не произойдет.)
Это означает, что вам нужно установить Git для Windows, настроенную среду выполнения msys2, чтобы иметь полностью рабочий git внутри MSYS2.


Обратите внимание, что после фиксации aeb582a9 (Git 2.22, Q2 2019) проект Git для Windows запустил процесс обновления до версии MSYS2, основанной на Cygwin v3.x.

mingw: разрешить сборку с MSYS2 runtime v3.x

Недавно проект Git для Windows начал процесс обновления до версии MSYS2, основанной на Cygwin v3.x.

Это имеет очень заметное следствие, что $(uname -r)больше не сообщает о версии, начинающейся с «2», а о версии с «3».

Это нарушает нашу сборку, так как df5218b ( config.mak.uname: support MSys2, 2016-01-13, Git v2.8.0-rc0) просто не ожидал, что версия, о которой сообщают, uname -rбудет зависеть от базовой версии Cygwin: она ожидала, что заявленная версия будет соответствовать " 2 "в" MSYS2 ".

Итак, давайте обратим этот контрольный пример для проверки чего-либо еще, кроме версии, начинающейся с «1» (для MSys).
Это должно защитить нас на будущее, даже если Cygwin в конечном итоге выпустит такие версии, как 314.272.65536.


Git 2.22 (Q2 2019) подготовит тест на будущее к обновлению серии MSYS2 runtime v3.x.

См. Коммит c871fbe (07 мая 2019 г.) Йоханнеса Шинделина ( dscho) .
(Слиты Junio C Hamano - gitster- в фиксации b20b8fe , 19 мая 2019)

t6500(mingw): используйте Windows PID оболочки

В Git для Windows мы используем MSYS2 Bash, который наследует нестандартную модель PID от уровня эмуляции POSIX Cygwin: каждый процесс MSYS2 имеет обычный PID Windows, и, кроме того, он имеет PID MSYS2 (который соответствует теневому процессу, который эмулирует Обработка сигналов в стиле Unix).

При обновлении до среды выполнения MSYS2 v3.x к этому теневому процессу больше нельзя получить доступ OpenProcess(), и поэтому t6500 неправильно подумал, что процесс, на который ссылаются gc.pid(который на самом деле не является реальным gcпроцессом в этом контексте, но текущей оболочкой), больше не существуют.

Давайте исправим это, убедившись, что PID Windows записан gc.pidв этом тестовом сценарии, чтобы git.exeможно было понять, что этот процесс действительно все еще существует.

VonC
источник
1
Это поднимает очень интересный вопрос: поскольку Git для Windows уже основан на MSYS2, были ли двоичные файлы, не зависящие от уровня эмуляции, доступны в виде пакета MSYS2? @RayDonnelly выше упоминает, что команда MSYS2 была заинтересована в создании этих видов двоичных файлов, чтобы увидеть, какую разницу в производительности она делает.
jpmc26
4
Мы еще не полностью слились, нет. Мы работаем над этим, хотя.
Рэй Доннелли
4
Подробнее об этом ... Пока нет, пока пакет git MSYS2 по-прежнему связан с msys-2.0.dll, идет процесс объединения MSYS2 с Git для Windows, и как только это будет завершено, мы ожидаем просто отбросить наш пакет git для их полностью нативного, поскольку пакеты, связанные с msys-2.0.dll, существуют для поддержки создания нативного программного обеспечения и сами по себе не являются конечной целью.
Рэй Доннелли
1
@RayDonnelly Какой статус в данный момент? Если заменить Git для Windows на MSYS2 (управление пакетами!), Есть ли недостатки?
Брехт Мачиэльс
2
Вот еще один вопрос: чем отличаются msys / git от git-for-windows / mingw-w64-x86_64-git?
Брехт Machiels
18

Мое понимание связей между ними

  • Cygwin предлагает эмуляцию POSIX поверх окон
  • msys пытался упростить Cygwin, но устарел с 2010 года
  • msysGit - разрешено использование Git до 1.9.4 в Windows (можно назвать git-for-windows-1.X ), основанное на старой версии msys.
  • msys2 - упрощенный Cygwin, разветвленный из него, с изменениями из msys и синхронизированный с функциями от Cygwin, интегрированный с Pacman
  • MinGW - начальный MinGW, заброшенный с 2010 года
  • MinGW-w64 - более быстрая и лучшая интеграция с Windows, без POSIX
  • git-for-windows-2.x - предлагает Git из 2.X для Windows с использованием MinGW-64 , MinGW-32 и, когда это невозможно, с откатом на msys2

Сравните Cygwin, msys, msys2, MinGW, git-for-windows, msysGit

Скрипка с полным определением графа в русалке .

raisercostin
источник
1
Приятная графика. +1. «Git для Windows 1.0» действительно был сделан с максимальной отдачей: stackoverflow.com/a/1704687/6309 (о котором я упоминаю в stackoverflow.com/a/50555740/6309 )
VonC