Como o msys, o msys2 e o msysgit se relacionam?

Eu estive pesquisando, mas não consigo encontrar uma descrição completa do que está acontecendo com essas três versões do MSYS. (É perfeitamente possível que eu simplesmente não saiba o que procurar.) Entendo que o MSYS é uma porta mínima de ferramentas Linux para dar suporte ao desenvolvimento usando o MinGW, mas não estou claro sobre o relacionamento entre os três ou o equipes que os desenvolveram / mantêm.

Questões específicas a serem abordadas:

• Quais estão em desenvolvimento ativo? (Em particular, o MSYS está morto e o MSYS2 está ativo?)
• Qual é a relação entre os grupos que os mantêm? (Em particular, a equipe do MSYS criou o MSYS2?)
• O msysgit usa apenas um dos outros ou eles têm sua própria ramificação do MSYS?
• Algum destes é compatível?
• Existem problemas de compatibilidade com versões específicas do Windows para qualquer um desses?
• Um fornece os principais recursos sobre o outro?

Isenção de responsabilidade: sou desenvolvedor MSYS2

Embora o MSYS não esteja morto, eu diria que ele também não parece muito saudável. É um projeto iniciado pela equipe do MinGW há muitos anos como um fork do Cygwin que nunca o acompanhou.

O msysgit é uma bifurcação de uma versão um pouco mais antiga do MSYS com alguns patches personalizados, versões antigas do Bash e Perl e uma porta nativa do Git.

O MSYS2 é um projeto iniciado por Alexey Pavlov, da equipe mingw-builds (que são os empacotadores oficiais das cadeias de ferramentas MinGW-w64) como um garfo recente do Cygwin que rastreia de perto o último Cygwin para que ele não fique desatualizado. Alexey enviou os antigos patches do MSYS e adicionou alguns dos seus.

Além de fornecer as ferramentas Unix necessárias para compilar software nativo - o objetivo declarado do MSYS -, transportamos o gerenciador de pacotes Pacman do Arch Linux . Pacman é mais do que apenas gerenciar pacotes binários (embora faça isso muito bem). Possui uma infraestrutura de criação de software chamada makepkg que permite a criação de receitas (PKGBUILD e arquivos de correção) para a criação de software.

IMHO, a adoção do Pacman muda significativamente as coisas para o desenvolvimento de código aberto no Windows. Em vez de todos invadirem seus próprios scripts de shell sob medida para criar software de uma maneira incompatível e hodge-podge, os pacotes agora podem depender de outros pacotes e os arquivos PKGBUILD e os patches associados podem ser usados ​​como referência para a construção de novos PKGBUILDs. É o mais próximo de um sistema Linux que um Windows (nativo) pode obter (Arch Linux em particular) e permite a atualização simples de todos os pacotes instalados.

Nosso objetivo é o Windows XP SP3, no mínimo, e suportamos Windows de 32 e 64 bits. Pedimos que você nunca misture o MSYS2 com o msys ou o msysgit. O Pacman é usado para gerenciar todo o sistema e, como tal, arquivos de outros sistemas causarão conflitos.

Também tentamos atualizar nossos patches para os projetos que construímos e solicitamos ativamente contribuições de outros projetos de código aberto. Esperamos que outras pessoas achem fácil trabalhar conosco.

Nosso site principal está no SourceForge e contém links para nossos repositórios PKGBUILD. Também temos um site de instalação mais amigável no GitHub .

Sinta-se à vontade para se juntar a nós no IRC (oftc # msys2) se desejar obter mais informações.

O Git 2.8 (março de 2016) inclui uma confirmação muito detalhada que explica a importância do msys2 para o novo git-for-windows que substituiu o msysgit no início de 2015 .

Veja commit df5218b (13 de janeiro de 2016) por Johannes Schindelin ( dscho) .
^{(Mesclado por Junio ​​C Hamano - gitster- na confirmação 116a866 , 29 de janeiro de 2016)}

Por um longo tempo, o Git for Windows ficou para trás das versões 2.x do Git porque os desenvolvedores do Git for Windows queriam que esse grande salto coincidisse com um salto bem necessário do MSys para o MSys2.

Para entender por que esse é um problema tão grande, é preciso observar que muitas partes do Git não são escritas no C portátil, mas o Git depende de um shell POSIX e do Perl para estar disponível .

Para dar suporte aos scripts, o Git for Windows precisa fornecer uma camada mínima de emulação POSIX com Bash e Perl , e quando o esforço do Git for Windows começou em agosto de 2007, esse desenvolvedor decidiu usar o MSys, uma versão simplificada do Cygwin .
Conseqüentemente, o nome original do projeto era "msysGit" (o que, infelizmente, causou muita confusão porque poucos usuários do Windows conhecem o MSys e ainda menos cuidado).

Para compilar o código C do Git for Windows, o MSys também foi usado: possui duas versões do GNU C Compiler:

• um que vincula implicitamente à camada de emulação POSIX,
• e outro que tem como alvo a API simples do Win32 (com algumas funções de conveniência ativadas).

Os executáveis ​​do Git for Windows são criados usando o último e, portanto, são realmente apenas programas Win32. Para discernir os executáveis ​​que exigem a camada de emulação POSIX daqueles que não o fazem, os últimos são chamados MinGW (GNU mínimo para Windows) quando os primeiros são chamados de executáveis ​​MSys .

Essa dependência no MSys também enfrentou desafios:

• algumas de nossas alterações no tempo de execução do MSys - necessárias para suportar melhor o Git for Windows - não foram aceitas no upstream, portanto tivemos que manter nosso próprio fork.
• Além disso, o tempo de execução do MSys não foi desenvolvido para suportar, por exemplo, UTF-8 ou 64 bits e, além de não ter um sistema de gerenciamento de pacotes até muito mais tarde (quando mingw-getfoi introduzido), muitos pacotes fornecidos pelo projeto MSys / MinGW ficam para trás dos respectivos versões de código fonte, em particular Bash e OpenSSL.

Por um tempo, o projeto Git for Windows tentou remediar a situação tentando criar versões mais recentes desses pacotes, mas a situação rapidamente se tornou insustentável, especialmente com problemas como o bug do Heartbleed, que requer ação rápida que não tem nada a ver com o desenvolvimento do Git para Windows mais.

Felizmente, entretanto, o projeto MSys2 ( https://msys2.github.io/ ) surgiu e foi escolhido para ser a base do Git para Windows 2.x.
Assim como o MSys, o MSys2 é uma versão simplificada do Cygwin, mas é ativamente atualizada com o código-fonte do Cygwin .
Assim, ele já suporta internamente o Unicode e também oferece o suporte de 64 bits que ansiamos desde o início do projeto Git for Windows.

O MSys2 também portou o sistema de gerenciamento de pacotes Pacman do Arch Linux e o utiliza intensamente . Isso traz a mesma comodidade com a qual os usuários Linux estão acostumados a partir de yumou apt-get, e com os quais usuários MacOSX estão acostumados com Homebrew ou MacPorts, ou usuários BSD do sistema Ports, para o MSys2: um simples pacman -Syuatualizará todos os pacotes instalados para as versões mais recentes disponível atualmente.

O MSys2 também é muito ativo, geralmente fornecendo atualizações de pacotes várias vezes por semana.

Ainda foi necessário um esforço de dois meses para levar tudo a um estado em que a suíte de testes do Git passou, muitos mais meses até o lançamento do primeiro Git for Windows 2.x oficial e alguns patches ainda aguardam seu envio para os respectivos projetos upstream . No entanto, sem o MSys2, a modernização do Git for Windows simplesmente não teria acontecido .

Essa confirmação estabelece o trabalho básico para dar suporte às compilações do Git baseadas no MSys2.

Nos comentários , a pergunta foi feita em janeiro de 2016:

Como o Git for Windows já é baseado no MSYS2, os binários que não dependem da camada de emulação foram disponibilizados como um pacote MSYS2?

Ray Donnelly respondeu na época:

Ainda não nos fundimos completamente, não. Mas estamos trabalhando nisso.

Mas ... madz ressalta que, no início de 2017, esse esforço não deu certo.
Vejo:

• Alexpux/MSYS2-packages PR 786
• git-for-windows/git edição 284

O problema é que não posso contribuir com alterações que resultarão em um novo tempo de execução do msys2 em tempo hábil.
Porém, não é um grande problema: vou manter o fork do Git for Windows funcionando indefinidamente.

Portanto, o wiki menciona agora (2018):

O Git for Windows criou alguns patches para o tempo de execução msys2 que não foram enviados a montante. (Isso havia sido planejado, mas foi determinado no número 284 que provavelmente não estaria acontecendo.)
Isso significa que é necessário instalar o tempo de execução msys2-runtime personalizado do Git for Windows para ter um git totalmente funcional no MSYS2.

Observe que, desde o commit aeb582a9 (Git 2.22, Q2 2019), o projeto Git for Windows iniciou o processo de atualização para uma versão de tempo de execução do MSYS2 baseada no Cygwin v3.x.

mingw: permitir a criação com um tempo de execução MSYS2 v3.x

Recentemente, o projeto Git for Windows iniciou o processo de atualização para uma versão de tempo de execução MSYS2 baseada no Cygwin v3.x.

Isso tem a consequência muito notável de que $(uname -r)não relata mais uma versão iniciada com "2", mas uma versão com "3".

Isso interrompe nossa compilação, pois o df5218b ( config.mak.uname: support MSys2, 2016-01-13, Git v2.8.0-rc0) simplesmente não esperava que a versão relatada uname -rdependesse da versão subjacente do Cygwin: esperava que a versão relatada correspondesse ao " 2 "em" MSYS2 ".

Então, vamos inverter esse caso de teste para testar qualquer outra coisa que não seja uma versão iniciada com "1" (para MSys).
Isso deve nos proteger para o futuro, mesmo que o Cygwin acabe lançando versões como 314.272.65536.

O Git 2.22 (Q2 2019) fará um teste à prova do futuro contra uma atualização da série MSYS2 runtime v3.x.

Veja commit c871fbe (07 de maio de 2019) de Johannes Schindelin ( dscho) .
^{(Incorporado por Junio ​​C Hamano - gitster- in commit b20b8fe , 19 de maio de 2019)}

t6500(mingw): use o PID do Windows do shell

No Git for Windows, usamos o MSYS2 Bash, que herda um modelo PID não padrão da camada de emulação POSIX da Cygwin: todo processo MSYS2 possui um PID regular do Windows e, além disso, possui um PYS MSYS2 (que corresponde a um processo de sombra que emula Manipulação de sinal no estilo Unix).

Com a atualização para o tempo de execução MSYS2 v3.x, esse processo de sombra não pode mais ser acessado por OpenProcess()mais tempo e, portanto, o t6500 pensou incorretamente que o processo mencionado gc.pid(que não é realmente um gcprocesso real nesse contexto, mas o shell atual) não é mais existe.

Vamos corrigir isso, certificando-se de que o PID do Windows esteja gravado gc.pidneste script de teste para que git.exeseja possível entender que esse processo realmente existe.

Meu entendimento sobre as conexões entre eles é

• Cygwin oferece emulação POSIX em cima de janelas
• msys tentou simplificar o Cygwin, mas está obsoleto em 2010
• msysGit - Git permitido até 1.9.4 no Windows (poderia ser chamado git-for-windows-1.X ), com base em uma versão antiga do msys.
• msys2 - um Cygwin simplificado, bifurcado, com alterações do msys e mantido em sincronia com os recursos do Cygwin, integrados ao Pacman
• MinGW - MinGW inicial, abandonado a partir de 2010
• MinGW-w64 - uma integração mais rápida e melhor com o Windows, sem POSIX
• git-for-windows-2.x - oferece o Git do 2.X para Windows usando MinGW-64 , MinGW-32 e quando não é possível com um fallback para msys2

Brinque com a definição completa do gráfico na sereia .