W jaki sposób msys, msys2 i msysgit są ze sobą powiązane?

Szukałem w okolicy, ale nie mogę znaleźć dokładnego opisu tego, co się dzieje z tymi 3 wersjami MSYS. (Jest całkowicie możliwe, że po prostu nie wiem, czego szukać.) Rozumiem, że MSYS to minimalny port narzędzi Linuksa do wspierania programowania przy użyciu MinGW, ale nie jestem pewien, jaki jest związek między nimi trzema lub zespoły, które je opracowały / utrzymują.

Szczególne kwestie do rozwiązania:

• Które z nich są w trakcie aktywnego rozwoju? (W szczególności, czy MSYS jest martwy, a MSYS2 aktywny?)
• Jakie są relacje między grupami, które je utrzymują? (W szczególności, czy zespół MSYS stworzył MSYS2?)
• Czy msysgit używa tylko jednego z pozostałych, czy też ma własną gałąź MSYS?
• Czy któreś z nich są ze sobą zgodne?
• Czy są jakieś problemy ze zgodnością z określonymi wersjami systemu Windows dla któregokolwiek z nich?
• Czy jeden zapewnia główne funkcje w porównaniu z drugim?

Zastrzeżenie: jestem programistą MSYS2

Chociaż MSYS nie jest martwy, powiedziałbym, że nie wygląda też zbyt zdrowo. Jest to projekt rozpoczęty przez zespół MinGW wiele lat temu jako widelec Cygwin, który nigdy nie nadążał za Cygwin.

msysgit to rozwidlenie nieco starszej wersji MSYS z kilkoma niestandardowymi łatkami, starszymi wersjami Bash i Perl oraz natywnym portem Gita.

MSYS2 to projekt rozpoczęty przez Alexeya Pavlova z zespołu mingw-builds (którzy są oficjalnymi pakietami dla łańcuchów narzędzi MinGW-w64) jako niedawny fork Cygwin, który dokładnie śledzi najnowszego Cygwin, aby nie stał się nieaktualny. Alexey forward przeportował stare łatki MSYS i dodał kilka własnych.

Oprócz zapewnienia niezbędnych narzędzi uniksowych do kompilowania natywnego oprogramowania - deklarowanego celu MSYS - przenieśliśmy menedżera pakietów Pacman z Arch Linux . Pacman to coś więcej niż tylko zarządzanie pakietami binarnymi (choć robi to bardzo dobrze). Posiada infrastrukturę do tworzenia oprogramowania o nazwie makepkg, która umożliwia tworzenie receptur (PKGBUILD i pliki poprawek) do tworzenia oprogramowania.

IMHO, przyjęcie Pacmana znacząco zmienia rzeczy w programowaniu open source w systemie Windows. Zamiast każdego hakować własne skrypty powłoki na zamówienie, aby tworzyć oprogramowanie w niekompatybilny sposób, pakiety mogą teraz zależeć od innych pakietów, a pliki PKGBUILD i powiązane łaty mogą być używane jako odniesienie do tworzenia nowych PKGBUILD. Jest tak zbliżony do systemu Linux, jak (natywny) system Windows (w szczególności Arch Linux) i umożliwia prostą aktualizację wszystkich zainstalowanych pakietów.

Naszym celem jest co najmniej dodatek SP3 dla systemu Windows XP i obsługujemy zarówno 32-bitowy, jak i 64-bitowy system Windows. Prosimy, abyś nigdy nie mieszał MSYS2 z msys lub msysgit. Pacman służy do zarządzania całym systemem i jako taki, pliki z innych systemów będą powodować konflikty.

Staramy się również udostępniać nasze poprawki do projektów, które tworzymy i aktywnie zabiegamy o wsparcie innych projektów open source. Mamy nadzieję, że innym będzie łatwo z nami pracować.

Nasza główna strona internetowa znajduje się na SourceForge i zawiera linki do naszych repozytoriów PKGBUILD. Mamy również bardziej przyjazną dla użytkownika witrynę instalatora na GitHub .

Jeśli chcesz uzyskać więcej informacji, dołącz do nas na IRC (oftc # msys2).

Git 2.8 (marzec 2016) zawiera bardzo szczegółowe zatwierdzenie, które wyjaśnia znaczenie msys2 dla nowego git-for-windows, który zastąpił msysgit na początku 2015 roku .

Zobacz commit df5218b (13 stycznia 2016) autorstwa Johannesa Schindelina ( dscho) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zobowiązaniu 116a866 , 29 stycznia 2016 r.)}

Przez długi czas Git dla Windows pozostawał w tyle za wydaniami Git 2.x, ponieważ programiści Git dla Windows chcieli pozwolić, aby ten duży skok zbiegł się z bardzo potrzebnym skokiem z MSys do MSys2.

Aby zrozumieć, dlaczego jest to tak poważny problem, należy zauważyć, że wiele części Gita nie jest napisanych w przenośnym C, ale zamiast tego Git polega na powłoce POSIX i dostępności Perla .

Aby obsługiwać skrypty, Git for Windows musi dostarczać minimalną warstwę emulacji POSIX z wrzuconymi Bash i Perl , a kiedy prace nad Git for Windows rozpoczęły się w sierpniu 2007 roku, ten programista zdecydował się na użycie MSys, okrojonej wersji Cygwin .
W związku z tym oryginalna nazwa projektu brzmiała „msysGit” (co niestety spowodowało wiele zamieszania, ponieważ niewielu użytkowników systemu Windows wie o MSys, a jeszcze mniej troszczy się o to).

Aby skompilować kod C Git dla Windows, użyto również MSys: obsługuje on dwie wersje kompilatora GNU C:

• taki, który łączy się niejawnie z warstwą emulacji POSIX,
• i inny, który jest przeznaczony dla zwykłego interfejsu API Win32 (z wprowadzonymi kilkoma wygodnymi funkcjami).

Pliki wykonywalne Git dla systemu Windows są budowane przy użyciu tego ostatniego, dlatego tak naprawdę są tylko programami Win32. Aby odróżnić pliki wykonywalne wymagające warstwy emulacji POSIX od tych, które jej nie wymagają, te drugie nazywane są MinGW (Minimal GNU dla Windows), podczas gdy te pierwsze nazywane są plikami wykonywalnymi MSys .

Jednak to uzależnienie od MSys stanowiło wyzwanie:

• niektóre z naszych zmian w środowisku wykonawczym MSys - niezbędne do lepszej obsługi Git dla Windows - nie zostały zaakceptowane przez użytkowników, więc musieliśmy utrzymywać własne rozwidlenie.
• Ponadto środowisko uruchomieniowe MSys nie było dalej rozwijane w celu obsługi np. UTF-8 lub 64-bitowego, a oprócz braku systemu zarządzania pakietami aż do znacznie później (kiedy mingw-getzostał wprowadzony), wiele pakietów dostarczonych przez projekt MSys / MinGW pozostaje w tyle za odpowiednim wersje kodu źródłowego, w szczególności Bash i OpenSSL.

Przez pewien czas projekt Git for Windows próbował zaradzić tej sytuacji, próbując zbudować nowsze wersje tych pakietów, ale sytuacja szybko stała się nie do utrzymania, szczególnie w przypadku problemów takich jak błąd Heartbleed wymagający szybkiej akcji, która nie ma nic wspólnego z tworzeniem Gita dla Okna dalej.

Na szczęście w międzyczasie pojawił się projekt MSys2 ( https://msys2.github.io/ ) i został wybrany jako podstawa Git dla Windows 2.x.
Podobnie jak MSys, MSys2 jest okrojoną wersją Cygwin, ale jest aktywnie aktualizowany z kodem źródłowym Cygwin .
W ten sposób obsługuje już wewnętrznie Unicode, a także oferuje obsługę 64-bitową, za którą tęskniliśmy od początku projektu Git dla Windows.

MSys2 również przeportował system zarządzania pakietami Pacman z Arch Linux i intensywnie go używa . Daje to tę samą wygodę, do której użytkownicy Linuksa są przyzwyczajeni z yumlub apt-get, i do której użytkownicy MacOSX są przyzwyczajeni z Homebrew lub MacPorts lub użytkowników BSD z systemu Ports do MSys2: prosty pacman -Syuzaktualizuje wszystkie zainstalowane pakiety do najnowszych wersji obecnie dostępne.

MSys2 jest również bardzo aktywny, zazwyczaj dostarcza aktualizacje pakietów kilka razy w tygodniu.

Nadal wymagało to dwumiesięcznego wysiłku, aby doprowadzić wszystko do stanu, w którym przechodzi pakiet testowy Gita, wiele miesięcy, zanim został wydany pierwszy oficjalny Git dla Windows 2.x, a kilka poprawek wciąż czeka na ich przesłanie do odpowiednich projektów. . Jednak bez MSys2 modernizacja Git dla Windows po prostu nie nastąpiłaby .

To zobowiązanie kładzie podwaliny pod obsługę kompilacji Git opartych na MSys2.

W komentarzach pytanie padło w styczniu 2016 roku:

Ponieważ Git dla Windows jest już oparty na MSYS2, czy pliki binarne, które nie zależą od warstwy emulacji, zostały udostępnione jako pakiet MSYS2?

Ray Donnelly odpowiedział wtedy:

Nie połączyliśmy się jeszcze w pełni, nie. Jednak pracujemy nad tym.

Ale ... madz zwraca uwagę, że na początku 2017 roku ten wysiłek się nie udał .
Widzieć:

• Alexpux/MSYS2-packages PR 786
• git-for-windows/git nr 284

Problem polega na tym, że nie mogę wnieść zmian, które spowodują nowe środowisko uruchomieniowe msys2 w odpowiednim czasie.
Nie jest to jednak duży problem: po prostu utrzymam rozwidlenie Git dla Windows działające w nieskończoność.

Dlatego wiki wspomina teraz (2018):

Git dla Windows stworzył kilka łatek dla msys2-runtime, które nie zostały wysłane do klienta. (Było to zaplanowane, ale w numerze 284 ustalono, że prawdopodobnie tak się nie stanie).
Oznacza to, że musisz zainstalować Git for Windows dostosowany do środowiska uruchomieniowego msys2-runtime, aby mieć w pełni działającego gita wewnątrz MSYS2.

Zwróć uwagę, że od wydania aeb582a9 (Git 2.22, Q2 2019) projekt Git for Windows rozpoczął proces aktualizacji do wersji środowiska uruchomieniowego MSYS2 opartej na Cygwin v3.x.

mingw: zezwól na budowanie za pomocą środowiska uruchomieniowego MSYS2 v3.x

Niedawno projekt Git for Windows rozpoczął proces aktualizacji do wersji uruchomieniowej MSYS2 opartej na Cygwin v3.x.

Ma to bardzo godną uwagi konsekwencję, że $(uname -r)nie zgłasza już wersji zaczynającej się od „2”, ale wersja z „3”.

To psuje naszą kompilację, ponieważ df5218b ( config.mak.uname: wsparcie MSys2, 2016-01-13, Git v2.8.0-rc0) po prostu nie spodziewał się, że wersja zgłoszona przez uname -rbędzie zależała od podstawowej wersji Cygwin: oczekiwał, że zgłoszona wersja będzie pasować do " 2 "w" MSYS2 ".

Odwróćmy więc ten przypadek testowy, aby przetestować coś innego niż wersja zaczynająca się od „1” (dla MSys).
To powinno nas zabezpieczyć na przyszłość, nawet jeśli Cygwin ostatecznie wyda wersje takie jak 314.272.65536.

Git 2.22 (drugi kwartał 2019 r.) Zapewni przyszłe testy pod kątem aktualizacji do serii MSYS2 runtime v3.x.

Zobacz commit c871fbe (7 maja 2019) autorstwa Johannesa Schindelina ( dscho) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu b20b8fe , 19 maja 2019 r.)}

t6500(mingw): użyj PID Windows powłoki

W Git dla Windows używamy MSYS2 Bash, który dziedziczy niestandardowy model PID z warstwy emulującej POSIX Cygwin: każdy proces MSYS2 ma zwykły PID Windows, a ponadto ma MSYS2 PID (który odpowiada procesowi w tle, który emuluje Obsługa sygnałów w stylu uniksowym).

Po uaktualnieniu do środowiska uruchomieniowego MSYS2 v3.x, ten proces w tle nie jest OpenProcess()już dostępny, dlatego t6500 pomyślał niepoprawnie, że proces, do którego się odwołuje gc.pid(który w rzeczywistości nie jest rzeczywistym gcprocesem w tym kontekście, ale bieżącą powłoką) już nie istnieje.

Naprawmy to, upewniając się, że PID systemu Windows jest zapisany gc.pidw tym skrypcie testowym, aby git.exebył w stanie zrozumieć, że ten proces rzeczywiście nadal istnieje.

Moje rozumienie powiązań między nimi jest takie

• Cygwin oferuje emulację POSIX w górnej części okien
• msys próbował uprościć Cygwin, ale od 2010 roku jest przestarzały
• msysGit - dozwolone Git do 1.9.4 w systemie Windows (można nazwać git-for-windows-1.X ), oparty na starej wersji msys.
• msys2 - uproszczony Cygwin, rozwidlony z niego, ze zmianami z msys i utrzymywany w synchronizacji z funkcjami Cygwin, zintegrowany z Pacmanem
• MinGW - początkowe MinGW, zaniechane od 2010 roku
• MinGW-w64 - szybsza i lepsza integracja z oknami, bez POSIX
• git-for-windows-2.x - oferuje Git od 2.X dla Windows przy użyciu MinGW-64 , MinGW-32 i kiedy nie jest to możliwe, z powrotem do msys2

Fiddle z pełną definicją wykresu w syrenie .