webentwicklung-frage-antwort-db.com.de

In welcher Beziehung stehen msys, msys2 und msysgit zueinander?

Ich habe herumgesucht, aber ich kann keine gründliche Beschreibung finden, was mit diesen 3 Versionen von MSYS los ist. (Es ist durchaus möglich, dass ich nicht weiß, wonach ich suchen soll.) Ich verstehe, dass MSYS eine minimale Portierung von Linux-Tools ist, um die Entwicklung mit MinGW zu unterstützen, aber mir ist nicht klar, in welcher Beziehung sie zueinander stehen Teams, die sie entwickelt/unterhalten.

Besondere zu behandelnde Probleme:

  • Welche sind in der aktiven Entwicklung? (Insbesondere ist MSYS tot und MSYS2 aktiv?)
  • In welcher Beziehung stehen die Gruppen, die sie unterhalten? (Hat das MSYS-Team insbesondere MSYS2 erstellt?)
  • Verwendet msysgit nur einen der anderen oder hat er einen eigenen MSYS-Zweig?
  • Sind alle miteinander kompatibel?
  • Gibt es Kompatibilitätsprobleme mit bestimmten Windows-Versionen?
  • Bietet einer wichtige Funktionen gegenüber dem anderen?
150
jpmc26

Haftungsausschluss: Ich bin ein MSYS2-Entwickler

Während MSYS nicht tot ist, würde ich sagen, dass es auch nicht sehr gesund aussieht. Es ist ein Projekt, das das mingw-Team vor vielen Jahren als eine Abzweigung von Cygwin gestartet hat, die nie mit Cygwin Schritt gehalten hat.

msysgit ist ein Zweig einer etwas älteren Version von MSYS mit einigen benutzerdefinierten Patches, alten Versionen von bash und Perl und einem nativen Port von git.

MSYS2 ist ein Projekt, das von Alexey Pavlov vom mingw-builds-Team (die die offiziellen Paketierer für MinGW-w64-Toolchains sind) als eine aktuelle Abzweigung von Cygwin gestartet wurde. Dies verfolgt das neueste Cygwin genau, damit es nicht veraltet ist. Alexey hat die alten MSYS-Patches portiert und einige seiner eigenen hinzugefügt.

Neben der Bereitstellung der notwendigen Unix-Tools für die Kompilierung nativer Software - das erklärte Ziel von MSYS - haben wir den Pacman-Paketmanager von Arch Linux portiert. Pacman ist mehr als nur das Verwalten von Binärpaketen (obwohl es das sehr gut macht). Es verfügt über eine Software-Infrastruktur namens makepkg, mit der Rezepte (PKGBUILD- und Patch-Dateien) zum Erstellen von Software erstellt werden können. IMHO die Annahme von Pacman ändert die Dinge für die Open Source-Entwicklung unter Windows erheblich. Anstatt dass jeder auf eigene Weise maßgeschneiderte Shell-Skripte hackt, um Software inkompatibel zu erstellen, können Pakete nun von anderen Paketen abhängen und PKGBUILD-Dateien und zugehörige Patches können als Referenz für die Erstellung neuer PKGBUILDs verwendet werden. Es kommt einem Linux-System so nahe, wie es ein (natives) Windows bekommen kann (insbesondere Arch) und ermöglicht die einfache Aktualisierung aller installierten Pakete.

Wir haben Windows XP SP3 als Minimum und unterstützen sowohl 32-Bit- als auch 64-Bit-Windows. Wir möchten Sie bitten, MSYS2 niemals mit msys oder msysgit zu mischen. Pacman wird zur Verwaltung des gesamten Systems verwendet. Dateien von anderen Systemen verursachen Konflikte.

Wir versuchen auch, unsere Patches für die von uns erstellten Projekte zu aktualisieren und Beiträge von anderen Open Source-Projekten aktiv einzuholen. Wir hoffen, dass andere es leicht finden, mit uns zu arbeiten.

Unsere Hauptwebsite ist auf Sourceforge und enthält Links zu unseren PKGBUILD-Repositories. Wir haben auch eine benutzerfreundlichere Installationsseite auf github .

Fühlen Sie sich frei, uns auf IRC (oftc # msys2) beizutreten, wenn Sie weitere Informationen wünschen.

165
Ray Donnelly

Git 2.8 (März 2016) enthält ein sehr detailliertes Commit, das die Bedeutung von msys2 für das neue Git-for-Windows erklärt, das msysgit Anfang 2015 ersetzte .

Siehe commit df5218b (13. Januar 2016) von Johannes Schindelin (dscho) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in Commit 116a866 , 29. Januar 2016)

Git für Windows blieb lange Zeit hinter Gits 2.x-Versionen zurück, da die Git für Windows-Entwickler diesen großen Sprung mit einem dringend benötigten Sprung von MSys zu MSys2 zusammenfallen lassen wollten.

Um zu verstehen, warum dies ein so großes Problem ist , muss beachtet werden, dass viele Teile von Git nicht in portierbarem C geschrieben sind, sondern sich stattdessen auf eine POSIX-Shell und Perl verlassen, um verfügbar zu sein .

Um die Skripte zu unterstützen, muss Git für Windows eine minimale POSIX-Emulationsebene mit Bash und Perl enthalten, und wann der Git für Windows-Aufwand begann Im August 2007 entschied sich dieser Entwickler für MSys, eine abgespeckte Version von Cygwin .
Folglich lautete der ursprüngliche Name des Projekts "msysGit" (was leider zulotVerwirrung führte, da nur wenige Windows-Benutzer MSys kennen und noch weniger Pflege).

Um den C-Code von Git für Windows zu kompilieren, wurde auch MSys verwendet: Es enthält zwei Versionen des GNU C-Compilers:

  • eine, die implizit mit der POSIX-Emulationsebene verknüpft ist,
  • und eine andere, die auf die einfache Win32-API abzielt (mit ein paar praktischen Funktionen).

Die ausführbaren Dateien von Git für Windows werden unter Verwendung der letzteren erstellt und sind daher eigentlich nur Win32-Programme. Um ausführbare Dateien, die die POSIX-Emulationsebene benötigen, von denen zu unterscheiden, die dies nicht tun, werden letztere als MinGW (Minimal GNU für Windows) bezeichnet, während erstere als MSys bezeichnet werden ausführbare Dateien .

Dieses Vertrauen in MSys brachte jedoch auch folgende Herausforderungen mit sich:

  • einige unserer Änderungen an der MSys-Laufzeitumgebung, die für eine bessere Unterstützung von Git für Windows erforderlich sind, wurden nicht übernommen, sodass wir unseren eigenen Fork beibehalten mussten.
  • Auch wurde die MSys-Laufzeit nicht weiterentwickelt, um z.B. UTF-8 oder 64-Bit, und abgesehen davon, dass ein Paketverwaltungssystem erst viel später (als mingw-get Eingeführt wurde) fehlte, hinken viele Pakete, die vom MSys/MinGW-Projekt bereitgestellt wurden, insbesondere den jeweiligen Quellcode-Versionen hinterher Bash und OpenSSL.

Eine Weile lang versuchte das Git für Windows-Projekt, Abhilfe zu schaffen, indem es versuchte, neuere Versionen dieser Pakete zu erstellen, aber die Situation wurde schnell unhaltbar, insbesondere bei Problemen wie dem Heartbleed-Fehler, der Swift action erforderte Das hat nichts mit der Weiterentwicklung von Git für Windows zu tun.

Glücklicherweise ist in der Zwischenzeit das MSys2-Projekt ( https://msys2.github.io/ ) entstanden, das als Basis für Git for Windows 2.x ausgewählt wurde.
Genau wie MSys ist MSys2 eine abgespeckte Version von Cygwin, wird jedoch aktiv mit dem Quellcode von Cygwin auf dem neuesten Stand gehalten .
Dadurch unterstützt es Unicode bereits intern und bietet auch die 64-Bit-Unterstützung, nach der wir uns seit Beginn des Git for Windows-Projekts sehnten.

MSys2 portierte auch das Pacman-Paketverwaltungssystem von Arch Linux und verwendet es in großem Umfang . Dies bietet den gleichen Komfort, an den Linux-Benutzer von yum oder apt-get Gewöhnt sind, und an den MacOSX-Benutzer von Homebrew oder MacPorts oder BSD-Benutzer vom Ports-System zu MSys2 : Ein einfaches pacman -Syu aktualisiert alle installierten Pakete auf die aktuellsten Versionen.

MSys2 ist auchveryactive und stellt in der Regel mehrmals pro Woche Paketaktualisierungen bereit.

Es dauerte noch zwei Monate, bis alles in einen Zustand gebracht war, in dem Gits Testsuite abgelaufen war, viele weitere Monate, bis das erste offizielle Git für Windows 2.x veröffentlicht wurde und noch einige Patches für die jeweiligen vorgelagerten Projekte vorliegen . Ohne MSys2 wäre die Modernisierung von Git für Windows einfach nicht gelungen .

Dieses Commit bildet die Grundlage für die Unterstützung von MSys2-basierten Git-Builds.


In den Kommentaren wurde die Frage im Januar 2016 gestellt:

Da Git für Windows bereits auf MSYS2 basiert, wurden die Binärdateien, die nicht von der Emulationsebene abhängen, als MSYS2-Paket zur Verfügung gestellt?

Ray Donnelly antwortete zu der Zeit:

Wir sind noch nicht vollständig zusammengeschlossen, nein. Wir arbeiten daran.

Aber ... madzweist darauf hin, dass sich diese Bemühungen Anfang 2017 nicht ausgewirkt haben.
Sehen:

Das Problem ist, dass ich keine Änderungen einbringen kann, die rechtzeitig zu einer neuen msys2-Laufzeit führen.
Aber kein großes Problem: Ich lasse die Fork von Git für Windows auf unbestimmte Zeit laufen.

Das Wiki erwähnt daher jetzt (2018):

Git für Windows hat einige Patches für msys2-runtime erstellt, die nicht upstream gesendet wurden. (Dies war geplant, aber in Ausgabe 284 wurde festgestellt, dass es wahrscheinlich nicht passieren würde.)
Dies bedeutet, dass Sie die von Git für Windows angepasste msys2-Runtime installieren müssen, um einen voll funktionsfähigen Git in MSYS2 zu haben.


Beachten Sie, dass das Git für Windows-Projekt seit dem Festschreiben von aeb582a9 (Git 2.22, Q2 2019) den Upgradeprozess auf eine MSYS2-Laufzeitversion auf der Basis von Cygwin v3.x gestartet hat.

mingw: Ermöglicht das Erstellen mit einer MSYS2-Laufzeitversion 3.x.

Kürzlich hat das Git for Windows-Projekt den Upgrade-Prozess auf eine MSYS2-Laufzeitversion auf Basis von Cygwin v3.x gestartet.

Dies hat die bemerkenswerte Konsequenz, dass $(uname -r) keine Version mehr meldet, die mit "2" beginnt, sondern eine Version mit "3".

Das bricht unseren Build, da df5218b (config.mak.uname: Unterstützung für MSys2, 2016-01-13, Git v2.8.0-rc0) einfach nicht mit der angegebenen Version gerechnet hat von uname -r abhängig von der zugrunde liegenden Cygwin-Version: Es wurde erwartet, dass die gemeldete Version mit der "2" in "MSYS2" übereinstimmt.

Kehren wir also diesen Testfall um, um nachetwas anderemzu suchen als nach einer Version, die mit "1" beginnt (für MSys).
Das sollte uns für die Zukunft sichern, auch wenn Cygwin am Ende Versionen wie 314.272.65536 veröffentlicht.


Git 2.22 (Q2 2019) wird einen Test gegen ein Update auf MSYS2 Runtime v3.x Series zukunftssicher machen.

Siehe commit c871fbe (07. Mai 2019) von Johannes Schindelin (dscho) .
(Zusammengeführt von Junio ​​C Hamano - gitster - in Commit b20b8fe , 19. Mai 2019)

t6500(mingw): benutze die Windows PID der Shell

In Git für Windows verwenden wir MSYS2 Bash, das ein nicht standardmäßiges PID-Modell von Cygwins POSIX-Emulationsebene erbt: Jeder MSYS2-Prozess verfügt über eine reguläre Windows-PID und darüber hinaus über eine MSYS2-PID (die einem emulierten Schattenprozess entspricht) Unix-artiges Signalhandling).

Mit dem Upgrade auf die MSYS2-Runtime v3.x kann auf diesen Shadow-Prozess nicht mehr über OpenProcess() zugegriffen werden, und daher dachte t6500 fälschlicherweise, dass der in gc.pid Angegebene Prozess kein realer gc -Prozess in diesem Kontext, aber die aktuelle Shell existiert nicht mehr.

Lassen Sie uns dies beheben, indem Sie sicherstellen, dass die Windows-PID in diesem Testskript in gc.pid Geschrieben ist, damit git.exe Verstehen kann, dass dieser Prozess tatsächlich noch vorhanden ist.

63
VonC

Mein Verständnis für die Verbindungen zwischen ihnen ist

  • cygwin bietet POSIX-Emulation über Windows an
  • msys hat versucht, cygwin zu vereinfachen, ist jedoch seit 2010 veraltet
  • msysGit - erlaubt git bis 1.9.4 in windwos (könnte als git-for-windows-1 bezeichnet werden. X ), basierend auf einer alten Version von msys.
  • msys2 - ein vereinfachtes Cygwin, das mit Änderungen von msys verzahnt und mit Funktionen von Cygwin synchronisiert ist, die in Pacman integriert sind
  • minGW - anfängliches minGW, aufgegeben ab 2010
  • minGW-w64 - eine schnellere und bessere Integration mit Windows ohne POSIX
  • git-for-windows-2.x - bietet git von 2.X für Windows mit minGW-64 , minGW-32 und wann nicht möglich mit einem Fallback auf msys2

compare cygwin, msys, msys2, minGW, git-for-windows, msysGit

Geige mit vollständige Graphdefinition in Meerjungfra

9
raisercostin