Як msys, msys2 та msysgit пов'язані між собою?

Я шукав навколо, але не можу знайти ґрунтовний опис того, що відбувається з цими 3 версіями MSYS. (Цілком можливо, я просто не знаю, на що звертати увагу.) Я розумію, що MSYS - це мінімальний порт інструментів Linux для підтримки розробки за допомогою MinGW, але мені не зрозуміло відносини між ними трьома або команди, які їх розробляли / підтримували.

Конкретні питання, які потрібно вирішити:

• Які з них перебувають в активному розвитку? (Зокрема, MSYS загинув і MSYS2 активний?)
• Який взаємозв'язок між групами, які їх підтримують? (Зокрема, чи створила команда MSYS MSYS2?)
• Чи msysgit просто використовує один з інших, чи вони мають власну гілку MSYS?
• Чи сумісні вони між собою?
• Чи є проблеми сумісності з певними версіями Windows для будь-якого з них?
• Чи надає одна основні функції в порівнянні з іншими?

Відмова: Я - розробник 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 та файли патчів) для створення програмного забезпечення.

IMHO, прийняття Pacman істотно змінює речі для розробки з відкритим кодом у Windows. Замість того, щоб усі хакірували власні сценарії оболонки, щоб створити програмне забезпечення у невідповідному вигляді, несумісний спосіб, пакети тепер можуть залежати від інших пакетів, а PKGBUILD файли та пов'язані з ними патчі можуть використовуватися як орієнтир для побудови нових PKGBUILD. Він настільки близький до системи Linux, як і (рідний) Windows, який може отримати (зокрема, Arch Linux) і дозволяє просте оновлення всіх встановлених пакетів.

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

Ми також намагаємось виправляти свої патчі до проектів, які ми створюємо, і активно вимагаємо від інших проектів з відкритим кодом. Ми сподіваємось, що іншим легко працювати з нами.

Наш головний веб-сайт знаходиться на SourceForge , і він містить посилання на наші сховища PKGBUILD. На GitHub у нас є і більш зручний сайт для встановлення .

Не соромтеся приєднатися до нас на IRC (oftc # msys2), якщо ви хочете отримати додаткову інформацію.

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

Див. Комісію df5218b (13 січня 2016) Йоганнеса Шинделіна ( dscho) .
^{(Об’єднав Хуніо С Хамано - gitster- у комітеті 116a866 , 29 січня 2016 р.)}

Тривалий час Git для Windows відставав від версії 2.x від Git, оскільки розробники Git для Windows хотіли, щоб цей великий стрибок збігався з необхідним стрибком від MSys до MSys2.

Щоб зрозуміти, чому це така велика проблема, потрібно зазначити, що багато частин Git написані не на портативному C, а натомість Git покладається на оболонку POSIX, а Perl буде доступний .

Для підтримки сценаріїв, Git для Windows повинен поставити мінімальний емуляційний шар POSIX з викинутими Bash та Perl , і коли зусилля Git для Windows розпочалися в серпні 2007 року, цей розробник вирішив використовувати MSys, зняту версію Cygwin .
Отже, початкова назва проекту була "msysGit" (що, на жаль, викликало багато плутанини, оскільки мало хто з користувачів Windows знає про MSys, а тим більше турбот).

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

• той, який неявно посилається на емуляційний шар POSIX,
• та інший, який націлений на звичайний API Win32 (з кількома зручними функціями).

Git для виконуваних файлів Windows будується за допомогою останнього, тому вони справді просто програми Win32. Для розрізнення виконуваних файлів, які потребують емуляційного рівня POSIX, від тих, що їх немає, останні називаються MinGW (Мінімальний GNU для Windows), коли перші називаються виконуваними файлами MSys .

Однак, покладаючись на MSys, також виникли проблеми:

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

Деякий час проект Git для Windows намагався виправити ситуацію, намагаючись створити новіші версії цих пакетів, але ситуація швидко стала неможливою, особливо з такими проблемами, як помилка Heartbleed, що вимагає швидких дій, що не має нічого спільного з розробкою Git для Windows далі.

На щастя, тим часом з'явився проект 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 з системи Ports, до MSys2: проста pacman -Syuоновить усі встановлені пакети до новіших версій На даний момент доступні.

MSys2 також дуже активний, зазвичай забезпечує оновлення пакунків кілька разів на тиждень.

Ще потрібно двомісячні зусилля, щоб довести все до стану, коли проходить тестовий набір Git, ще багато місяців до виходу першого офіційного Git для Windows 2.x, і ще кілька патчів чекають їх подання у відповідні проекти за течією . Однак без MSys2 модернізація Git для Windows просто не відбулася б .

Це зобов'язання покладає основні роботи щодо підтримки побудови на базі MSys2.

У коментарях питання було задано у січні 2016 року:

Оскільки Git для Windows вже базується на MSYS2, чи двійкові файли, які не залежать від рівня емуляції, стали доступними як пакет MSYS2?

Рей Доннеллі в той час відповів:

Ми ще не повністю злилися, ні. Ми над цим працюємо.

Але ... madz вказує, що на початку 2017 року ці зусилля не збивалися .
Побачити:

• Alexpux/MSYS2-packages PR 786
• git-for-windows/git випуск 284

Проблема полягає в тому, що я не можу внести зміни, які спричинить за собою новий 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 часу виконання v3.x

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

Це має дуже помітний наслідок, що $(uname -r)вже не повідомляється про версію, що починається з "2", а версія з "3".

Це порушує нашу збірку, оскільки df5218b ( config.mak.uname: підтримка 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 для версії v3.x.

Див. Комісію c871fbe (07 травня 2019 р.) Йоганнеса Шинделіна ( dscho) .
^{(Об’єднав Хуніо С Хамано - gitster- в комітеті b20b8fe , 19 травня 2019 р.)}

t6500(mingw): використовувати Windows PID оболонки

У Git для Windows ми використовуємо MSYS2 Bash, який успадковує нестандартну модель PID від рівня емуляції POSG Cygwin: кожен процес MSYS2 має звичайний PID для Windows, а крім того, він має MSYS2 PID (що відповідає тіньовому процесу, який емулює Обробка сигналу в стилі Unix).

З оновленням до MSYS2 виконуваної версії v3.x, до цього тіньового процесу неможливо отримати доступ OpenProcess()більше, і тому t6500 неправильно вважав, що процес, на який посилається gc.pid(який насправді не є реальним gcпроцесом у цьому контексті, але поточною оболонкою), вже не є існує.

Давайте виправимо це, переконавшись, що gc.pidв цьому тестовому сценарії записано PID Windows, щоб git.exeвін міг зрозуміти, що цей процес все ще існує.

Моє розуміння зв’язків між ними

• 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

Скрипка з повним визначенням графіка у русалки .