Comment msys, msys2 et msysgit sont-ils liés les uns aux autres?

J'ai cherché, mais je ne trouve pas de description détaillée de ce qui se passe avec ces 3 versions de MSYS. (Il est tout à fait possible que je ne sais pas quoi chercher.) Je comprends que MSYS est un port minimal d'outils Linux pour prendre en charge le développement à l'aide de MinGW, mais je ne suis pas clair sur la relation entre les trois ou le les équipes qui les ont développés / maintenus.

Problèmes particuliers à résoudre:

• Lesquels sont en cours de développement actif? (En particulier, MSYS est-il mort et MSYS2 actif?)
• Quelle est la relation entre les groupes qui les maintiennent? (En particulier, l'équipe MSYS a-t-elle créé MSYS2?)
• Est-ce que msysgit utilise simplement l'un des autres, ou ont-ils leur propre branche de MSYS?
• Certains de ces éléments sont-ils compatibles les uns avec les autres?
• Existe-t-il des problèmes de compatibilité avec certaines versions de Windows pour l'un de ces problèmes?
• L'un offre-t-il des fonctionnalités importantes par rapport à l'autre?

Avertissement: Je suis un développeur MSYS2

Bien que MSYS ne soit pas mort, je dirais que cela n'a pas l'air très sain non plus. C'est un projet lancé par l'équipe MinGW il y a de nombreuses années en tant que fork de Cygwin qui n'a jamais suivi le rythme de Cygwin.

msysgit est un fork d'une version légèrement plus ancienne de MSYS avec quelques correctifs personnalisés, d'anciennes versions de Bash et Perl et un port natif de Git.

MSYS2 est un projet lancé par Alexey Pavlov de l'équipe mingw-builds (qui sont les packagers officiels des chaînes d'outils MinGW-w64) en tant que fork récent de Cygwin qui suit de près le dernier Cygwin afin qu'il ne soit pas obsolète. Alexey forward a porté les anciens correctifs MSYS et en a ajouté quelques-uns.

En plus de fournir les outils Unix nécessaires pour compiler des logiciels natifs - l'objectif déclaré de MSYS - nous avons porté le gestionnaire de paquets Pacman d' Arch Linux . Pacman ne consiste pas seulement à gérer des paquets binaires (bien qu'il le fasse très bien). Il dispose d'une infrastructure de création de logiciels appelée makepkg qui permet la création de recettes (PKGBUILD et fichiers de correctifs) pour la création de logiciels.

À mon humble avis, l'adoption de Pacman change considérablement les choses pour le développement open source sur Windows. Au lieu que chacun pirate ses propres scripts shell sur mesure pour créer des logiciels d'une manière hodge-podge et incompatible, les packages peuvent désormais dépendre d'autres packages et les fichiers PKGBUILD et les correctifs associés peuvent être utilisés comme référence pour la construction de nouveaux PKGBUILD. Il est aussi proche d'un système Linux qu'un Windows (natif) peut l'être (Arch Linux en particulier) et permet une mise à jour simple de tous les packages installés.

Nous ciblons au minimum Windows XP SP3 et prenons en charge Windows 32 bits et 64 bits. Nous vous demandons de ne jamais mélanger MSYS2 avec msys ou msysgit. Pacman est utilisé pour gérer l'ensemble du système et en tant que tel, les fichiers des autres systèmes provoqueront des conflits.

Nous essayons également d'amont nos correctifs sur les projets que nous construisons et sollicitons activement les contributions d'autres projets open source. Nous espérons que d'autres trouveront facile de travailler avec nous.

Notre site Web principal est sur SourceForge et contient des liens vers nos dépôts PKGBUILD. Nous avons également un site d'installation plus convivial sur GitHub .

N'hésitez pas à nous rejoindre sur IRC (oftc # msys2) si vous souhaitez plus d'informations.

Git 2.8 (mars 2016) inclut un commit très détaillé qui explique l'importance de msys2 pour le nouveau git-for-windows qui a remplacé msysgit début 2015 .

Voir commit df5218b (13 janvier 2016) par Johannes Schindelin ( dscho) .
^{(Fusionné par Junio ​​C Hamano - gitster- dans commit 116a866 , 29 janvier 2016)}

Pendant longtemps, Git pour Windows a pris du retard par rapport aux versions 2.x de Git parce que les développeurs de Git pour Windows voulaient que ce grand saut coïncide avec un saut bien nécessaire de MSys à MSys2.

Pour comprendre pourquoi c'est un si gros problème, il faut noter que de nombreuses parties de Git ne sont pas écrites en C portable, mais à la place, Git s'appuie sur un shell POSIX et Perl pour être disponible .

Pour prendre en charge les scripts, Git pour Windows doit fournir une couche d'émulation POSIX minimale avec Bash et Perl , et lorsque l'effort Git pour Windows a commencé en août 2007, ce développeur a décidé d'utiliser MSys, une version allégée de Cygwin .
Par conséquent, le nom original du projet était "msysGit" (ce qui, malheureusement, a causé beaucoup de confusion car peu d'utilisateurs de Windows connaissent MSys, et encore moins de soins).

Pour compiler le code C de Git pour Windows, MSys a également été utilisé: il contient deux versions du compilateur GNU C:

• celui qui relie implicitement à la couche d'émulation POSIX,
• et un autre qui cible l'API Win32 ordinaire (avec quelques fonctions pratiques ajoutées).

Les exécutables de Git pour Windows sont construits en utilisant ce dernier, et donc ce ne sont en réalité que des programmes Win32. Pour discerner les exécutables nécessitant la couche d'émulation POSIX de ceux qui ne le font pas, ces derniers sont appelés MinGW (Minimal GNU pour Windows) alors que les premiers sont appelés exécutables MSys .

Cette dépendance envers MSys a également posé des problèmes:

• certaines de nos modifications apportées au runtime MSys - nécessaires pour mieux supporter Git pour Windows - n'ont pas été acceptées en amont, nous avons donc dû maintenir notre propre fork.
• En outre, le runtime MSys n'a pas été développé davantage pour prendre en charge, par exemple, UTF-8 ou 64 bits, et mis à part l'absence d'un système de gestion des packages jusqu'à beaucoup plus tard (lors de mingw-getson introduction), de nombreux packages fournis par le projet MSys / MinGW sont en retard sur les les versions de code source, en particulier Bash et OpenSSL.

Pendant un certain temps, le projet Git pour Windows a tenté de remédier à la situation en essayant de construire de nouvelles versions de ces packages, mais la situation est rapidement devenue intenable, en particulier avec des problèmes comme le bogue Heartbleed nécessitant une action rapide qui n'a rien à voir avec le développement de Git pour Windows plus loin.

Heureusement, entre-temps, le projet MSys2 ( https://msys2.github.io/ ) a vu le jour et a été choisi pour être la base du Git pour Windows 2.x.
Tout comme MSys, MSys2 est une version allégée de Cygwin, mais elle est activement maintenue à jour avec le code source de Cygwin .
De ce fait, il prend déjà en charge Unicode en interne, et il offre également le support 64 bits auquel nous aspirions depuis le début du projet Git pour Windows.

MSys2 a également porté le système de gestion de paquets Pacman d'Arch Linux et l'utilise beaucoup . Cela apporte la même commodité à laquelle les utilisateurs Linux sont habitués à partir de yumou apt-get, et à laquelle les utilisateurs MacOSX sont habitués de Homebrew ou MacPorts, ou des utilisateurs BSD du système Ports, à MSys2: un simple pacman -Syumettra à jour tous les packages installés vers les dernières versions actuellement disponible.

MSys2 est également très actif, fournissant généralement des mises à jour des packages plusieurs fois par semaine.

Il a fallu encore deux mois d'efforts pour tout amener à un état où la suite de tests de Git réussit, bien d'autres mois avant la sortie du premier Git officiel pour Windows 2.x, et quelques correctifs attendent toujours leur soumission aux projets en amont respectifs. . Pourtant, sans MSys2, la modernisation de Git pour Windows n'aurait tout simplement pas eu lieu .

Ce commit jette les bases de la prise en charge des builds Git basés sur MSys2.

Dans les commentaires , la question a été posée en janvier 2016:

Étant donné que Git pour Windows est déjà basé sur MSYS2, les binaires qui ne dépendent pas de la couche d'émulation ont-ils été rendus disponibles sous forme de package MSYS2?

Ray Donnelly a répondu à l'époque:

Nous n'avons pas encore complètement fusionné, non. Nous y travaillons cependant.

Mais ... madz souligne qu'au début de 2017, cet effort n'a pas abouti.
Voir:

• Alexpux/MSYS2-packages PR 786
• git-for-windows/git numéro 284

Le problème est que je ne peux pas apporter de modifications qui résulteront en un nouveau runtime msys2 en temps opportun.
Pas un gros problème, cependant: je vais simplement garder le fork de Git pour Windows indéfiniment.

Le wiki mentionne donc maintenant (2018):

Git pour Windows a créé des correctifs pour msys2-runtime qui n'ont pas été envoyés en amont. (Cela avait été planifié, mais il a été déterminé dans le numéro 284 que cela ne se produirait probablement pas.)
Cela signifie que vous devez installer Git pour Windows personnalisé msys2-runtime pour avoir un git entièrement fonctionnel dans MSYS2.

Notez que, depuis la validation aeb582a9 (Git 2.22, Q2 2019), le projet Git pour Windows a démarré le processus de mise à niveau vers une version d'exécution MSYS2 basée sur Cygwin v3.x.

mingw: autorise la construction avec un runtime MSYS2 v3.x

Récemment, le projet Git pour Windows a lancé le processus de mise à niveau vers une version d'exécution MSYS2 basée sur Cygwin v3.x.

Cela a pour conséquence très notable de $(uname -r)ne plus signaler une version commençant par "2", mais une version avec "3".

Cela casse notre build, car df5218b ( config.mak.uname: support MSys2, 2016-01-13, Git v2.8.0-rc0) ne s'attendait tout simplement pas à ce que la version rapportée par uname -rdépende de la version sous-jacente de Cygwin: il s'attendait à ce que la version rapportée corresponde à la " 2 "dans" MSYS2 ".

Alors inversons ce cas de test pour tester autre chose qu'une version commençant par "1" (pour MSys).
Cela devrait nous protéger pour l'avenir, même si Cygwin finit par publier des versions comme 314.272.65536.

Git 2.22 (Q2 2019) assurera la pérennité d'un test par rapport à une mise à jour de la série v3.x d'exécution MSYS2.

Voir commit c871fbe (07 mai 2019) par Johannes Schindelin ( dscho) .
^{(Fusionné par Junio ​​C Hamano - gitster- dans commit b20b8fe , 19 mai 2019)}

t6500(mingw): utilisez le PID Windows du shell

Dans Git pour Windows, nous utilisons le MSYS2 Bash qui hérite d'un modèle PID non standard de la couche d'émulation POSIX de Cygwin: chaque processus MSYS2 a un PID Windows normal, et en plus il a un PID MSYS2 (qui correspond à un processus d'ombre qui émule Gestion des signaux de style Unix).

Avec la mise à niveau vers le runtime MSYS2 v3.x, ce processus de duplication miroir n'est pas accessible via OpenProcess() , et donc t6500 pensait à tort que le processus référencé dans gc.pid(qui n'est pas réellement un gcprocessus réel dans ce contexte, mais le shell actuel) n'est plus existe.

Résolvons ce problème en nous assurant que le PID Windows est écrit dans gc.pidce script de test afin qu'il git.exepuisse comprendre que ce processus existe toujours.

Ma compréhension des liens entre eux est

• Cygwin propose une émulation POSIX au-dessus de Windows
• msys a essayé de simplifier Cygwin mais est obsolète depuis 2010
• msysGit - autorisé Git jusqu'à 1.9.4 sur Windows (pourrait être appelé git-for-windows-1.X ), basé sur une ancienne version de msys.
• msys2 - un Cygwin simplifié, dérivé de celui-ci, avec des modifications de msys et synchronisé avec les fonctionnalités de Cygwin, intégré à Pacman
• MinGW - initial, abandonné à partir de 2010
• MinGW-w64 - une intégration plus rapide et meilleure avec Windows, sans POSIX
• git-for-windows-2.x - propose Git à partir de 2.X pour Windows en utilisant MinGW-64 , MinGW-32 et quand n'est pas possible avec un retour à msys2

Violon avec définition graphique complète dans sirène .