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

162

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?
jpmc26
źródło
8
@JamesJohnston Przed napisaniem tego pytania rozumiałem (i jest), że MSYS i MinGW zostały stworzone jako konkurencja dla Cygwin, ponieważ Cygwin (przynajmniej wcześniej; nie jestem pewien jego obecnego stanu) wymusił przejście przez nowy kod raczej niewydajna warstwa zgodności zamiast bezpośredniego wywoływania interfejsów API systemu Windows. W związku z tym zawsze postrzegałem MSYS i jego krewnych jako lżejszy system niż Cygwin, więc nie interesował mnie obecny status Cygwin. To może być dobre pytanie uzupełniające, jeśli jesteś zainteresowany; nie wahaj się zapytać, czy możesz wyrazić to jako temat.
jpmc26
4
Ja też byłem pod takim wrażeniem, dopóki wczoraj nie zacząłem kopać pod kołdrą. Wszystkie trzy wersje MSYS, o których wspominasz, to rozwidlenia Cygwin, jak wskazuje @Ray Donnelly. W tym sensie wszyscy są „Cygwinami” - a to pytanie tak naprawdę dotyczy Cygwina i jego wideł. Jak wskazuje Ray, wygląda na to, że MSYS jest skazany na zagładę. Sam sprawdziłem kod MSYS; jest beznadziejnie przestarzały i brakuje mu nawet podstawowej synchronizacji w pamięci współdzielonej. Opiekunowie po prostu nie nadążali za upstreamem i nigdy nie dostali poprawek dla pamięci współdzielonej, które otrzymał Cygwin.
James Johnston
9
@JamesJohnston Myślę, że źle zrozumiałeś. Chodzi mi o to, że Cygwin nie obsługuje (nie?) Budowania nowych plików binarnych bez warstwy zgodności. MSYS i krewni robią to za pośrednictwem MinGW. W związku z tym nie interesuje mnie Cygwin, mimo że doskonale zdaję sobie sprawę, że wszyscy mają korzenie w Cygwin. Ponieważ nie interesuje mnie Cygwin, nie ma sensu pytać o to. To pytanie również skupia się przede wszystkim na historii samego rozwidlenia i jego przyczynach oraz niektórych podstawowych konsekwencjach. Kiedy próbujesz wybierać między różnymi wersjami MSYS, historia Cygwin nie jest tak naprawdę istotna.
jpmc26
1
Nie rozumiem, dlaczego programiści MSYS2 i programiści Cygwin nie mogą dojść do porozumienia i zakończyć kłótni, więc możemy przestać mieć te głupie widelce. Cygwinowi poświęca się niewiele uwagi, ale przynajmniej pracują nad tym opłacani pracownicy firmy Red Hat; widelce nawet tego nie rozumieją. Znalazłem dyskusję z zeszłego roku na liście mailingowej Cygwin o tym, że MSYS2 jest tylko biblioteką DLL przechwytującą dla Cygwin, aby MSYS2 nie musiał rozwidlać całej biblioteki Cygwin DLL; najwyraźniej te dyskusje nie zaszły daleko. Podczas gdy MSYS2 ma teraz energię, przewiduję stagnację jak MSYS, jeśli / kiedy wolontariusze MSYS2 przestaną go aktualizować
James Johnston
1
@JamesJohnston Myślę, że możesz uzyskać lepsze odpowiedzi na swoje pytania na kanale IRC, o którym Ray wspomina w swojej odpowiedzi. Ten łańcuch komentarzy staje się dość długi i odbiega od tematu.
jpmc26

Odpowiedzi:

178

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).

Ray Donnelly
źródło
6
Czy msys2 może być użyty do zbudowania i uruchomienia gita (tj. Zastąpienia msysgit).
eckes
10
MSYS2 ma pakiet git. Jest to wersja MSYS2 w przeciwieństwie do wersji natywnej. Aby zainstalować git: pacman -S git .. mamy również pracujący port msysgit w naszym repozytorium pakietów MINGW.
Ray Donnelly
16
Nie, nasz git MSYS2 jest kompletny i wolny od hacków. Używamy go szeroko przy tworzeniu innych pakietów. Istnieje obawa, że ​​MSYS2 (ponieważ jest to rozwidlenie Cygwin) dodaje sporo narzutów do operacji na plikach, a ponieważ git jest obciążony operacjami na plikach, natywny git byłby szybszy. Sposobem na udowodnienie lub obalenie tego jest posiadanie obu i porównanie ich z porównaniem, więc to właśnie zrobimy. Powinienem uważać na te terminy, ponieważ moje odniesienia do msysgit dotyczą dwóch różnych rzeczy, msys-fork z natywnym git systemu Windows, a także natywnym git systemu Windows. Tutaj mam na myśli to drugie!
Ray Donnelly,
7
@eckes Chcę tylko powiedzieć, że używam MSYS2 dla git od kilku miesięcy. MSYS2 ma kilka trudnych obszarów (jakie oprogramowanie nie ma?), Ale jestem bardzo zadowolony z jego używania. Żaden z nich nie był związany z samym gitem.
jpmc26
7
Obietnica msys2 spełnia moje oczekiwania. Tak trzymaj, @RayDonnelly
bvj
73

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ć:

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.

VonC
źródło
1
Rodzi to bardzo interesujące pytanie: skoro 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? @RayDonnelly powyżej wspomina, że ​​zespół MSYS2 był zainteresowany tworzeniem tego rodzaju plików binarnych, aby zobaczyć, jakie to powoduje różnicę w wydajności.
jpmc26
4
Nie połączyliśmy się jeszcze w pełni, nie. Jednak pracujemy nad tym.
Ray Donnelly
4
Aby to rozwinąć ... Jeszcze nie, na razie pakiet git MSYS2 nadal łączy się z msys-2.0.dll, trwa proces łączenia MSYS2 z Git dla Windows, a po jego zakończeniu spodziewamy się po prostu porzucić nasz pakiet git w pełni natywny, ponieważ istnieją pakiety połączone z msys-2.0.dll, które wspierają tworzenie oprogramowania natywnego i nie są celem samym w sobie.
Ray Donnelly
1
@RayDonnelly Jaki jest stan w tej chwili? Jeśli zastąpisz Git dla Windows MSYS2 (zarządzanie pakietami!), Czy są jakieś wady?
Brecht Machiels
18

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

Porównaj Cygwin, msys, msys2, MinGW, git-for-windows, msysGit

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

raisercostin
źródło
1
Ładna grafika. +1. „Git dla Windows 1.0” został jednak naprawdę wykonany z największą starannością: stackoverflow.com/a/1704687/6309 (o którym wspominam w stackoverflow.com/a/50555740/6309 )
VonC,