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?
8
@JamesJohnston Avant d'écrire cette question, il était (et est) ma compréhension que MSYS et MinGW ont été créés en tant que concurrents de Cygwin parce que Cygwin (au moins auparavant; je ne suis pas sûr de son état actuel) a forcé tout nouveau code à passer une couche de compatibilité plutôt non performante au lieu d'appeler directement les API Windows. En tant que tel, j'ai toujours vu MSYS et ses proches comme un système plus léger que Cygwin, donc je n'étais pas intéressé par le statut actuel de Cygwin. Cela pourrait faire une bonne question de suivi, si cela vous intéresse, cependant; N'hésitez pas à lui demander si vous pouvez le formuler pour être sur le sujet.
—
jpmc26
J'avais également cette impression jusqu'à ce que je commence à fouiller sous les couvertures hier. Les trois versions de MSYS que vous mentionnez sont des fourches de Cygwin, comme le souligne @Ray Donnelly. Donc, dans ce sens, ils sont tous "Cygwin" - et cette question concerne vraiment Cygwin et ses fourches. Comme le fait remarquer Ray, il semble que MSYS est condamné. J'ai examiné le code MSYS moi-même; il est désespérément obsolète et manque même de synchronisation de base sur la mémoire partagée. Les responsables n'ont tout simplement pas suivi le rythme en amont, et n'ont jamais obtenu les correctifs pour la mémoire partagée que Cygwin en amont avait.
—
James Johnston
@JamesJohnston Je pense que vous avez mal compris. Mon point est que Cygwin ne supporte pas (n'a pas?) La construction de nouveaux binaires sans la couche de compatibilité. MSYS et ses proches le font, via MinGW. En tant que tel, je ne suis pas intéressé par Cygwin, même si je suis bien conscient que tous ont des racines dans Cygwin. Comme je ne suis pas intéressé par Cygwin, cela n'a pas de sens de le demander. Cette question porte également principalement sur l' histoire de la fourche elle-même et les raisons de celle-ci et certaines conséquences rudimentaires de celle-ci. Lorsque vous essayez de choisir entre différentes versions de MSYS, l'historique de Cygwin n'est pas vraiment pertinent.
—
jpmc26
Ce que je ne comprends pas, c'est pourquoi les développeurs MSYS2 et Cygwin ne peuvent pas s'entendre et cesser de se chamailler pour que nous puissions arrêter d'avoir ces stupides fourchettes. Cygwin reçoit peu d'attention en l'état, mais au moins il y a des employés rémunérés de Red Hat qui travaillent dessus; les fourches ne comprennent même pas ça. J'ai trouvé la discussion de l'année dernière sur la liste de diffusion de Cygwin sur le fait que MSYS2 soit juste une DLL de hook pour Cygwin afin que MSYS2 n'ait pas à bifurquer la DLL Cygwin entière; apparemment, ces discussions ne sont pas allées loin. Alors que MSYS2 a de l'énergie maintenant, je prévois qu'il stagne comme MSYS si / quand les volontaires MSYS2 arrêtent de le mettre à jour
—
James Johnston
@JamesJohnston Je pense que vous pourrez peut-être obtenir de meilleures réponses à vos questions sur le canal IRC que Ray mentionne dans sa réponse. Cette chaîne de commentaires devient assez longue et s'écarte du sujet.
—
jpmc26
