Ho cercato in giro, ma non riesco a trovare una descrizione completa di ciò che sta accadendo con queste 3 versioni di MSYS. (È del tutto possibile non so proprio cosa cercare.) Capisco che MSYS è una porta minima di strumenti Linux per supportare lo sviluppo usando MinGW, ma non sono chiaro sulla relazione tra loro tre o il team che li hanno sviluppati / mantenuti.
Questioni particolari da affrontare:
- Quali sono in fase di sviluppo attivo? (In particolare, MSYS è morto e MSYS2 è attivo?)
- Qual è la relazione tra i gruppi che li mantengono? (In particolare, il team MSYS ha creato MSYS2?)
- Msysgit usa solo uno degli altri o ha il proprio ramo di MSYS?
- Alcuni di questi sono compatibili tra loro?
- Ci sono problemi di compatibilità con particolari versioni di Windows per una di queste?
- Uno fornisce le principali funzionalità rispetto all'altro?
8
@JamesJohnston Prima di scrivere questa domanda, era (ed è) la mia comprensione che MSYS e MinGW sono stati creati come concorrenti di Cygwin perché Cygwin (almeno in precedenza; non sono sicuro del suo stato attuale) ha costretto qualsiasi nuovo codice a passare un livello di compatibilità piuttosto non performante invece di chiamare direttamente le API di Windows. In quanto tale, ho sempre visto MSYS e i suoi parenti come un sistema più leggero di Cygwin, quindi non ero interessato allo stato attuale di Cygwin. Questo potrebbe fare una buona domanda di follow-up, se sei interessato, però; sentiti libero di chiederlo se riesci a formularlo per essere in tema.
—
jpmc26,
Ho avuto anche quell'impressione fino a quando non ho iniziato a scavare sotto le coperte ieri. Tutte e tre le versioni di MSYS citate sono forchette di Cygwin, come sottolinea @Ray Donnelly. Quindi, in questo senso, sono tutti "Cygwin" - e questa domanda riguarda davvero Cygwin e le sue forcelle. Come sottolinea Ray, sembra che MSYS sia condannato. Ho esaminato il codice MSYS da solo; è irrimediabilmente obsoleto e manca persino la sincronizzazione di base sulla memoria condivisa. I manutentori non hanno tenuto il passo con l'upstream e non hanno mai avuto le correzioni per la memoria condivisa che ha ottenuto l'upstream Cygwin.
—
James Johnston,
@JamesJohnston Penso che tu abbia frainteso. Il mio punto è che Cygwin non supporta (non?) La costruzione di nuovi binari senza il livello di compatibilità. MSYS e parenti lo fanno, tramite MinGW. In quanto tale, non mi interessa Cygwin, nonostante sia ben consapevole che tutti hanno radici in Cygwin. Dato che non sono interessato a Cygwin, non aveva senso chiederlo. Questa domanda si concentra anche principalmente sulla storia del biforcamento stesso e le ragioni di ciò e alcune conseguenze rudimentali di esso. Quando si tenta di scegliere tra diverse versioni di MSYS, la storia di Cygwin non è davvero rilevante.
—
jpmc26,
Quello che non capisco è il motivo per cui gli sviluppatori MSYS2 e gli sviluppatori Cygwin non possono venire a patti e smettere di litigare, quindi possiamo smettere di avere queste stupide forchette. Cygwin riceve poca attenzione così com'è, ma almeno ci sono dipendenti Red Hat retribuiti che ci lavorano; le forchette non lo capiscono nemmeno. Ho trovato una discussione dello scorso anno sulla mailing list di Cygwin sull'avere MSYS2 come una DLL hook per Cygwin in modo che MSYS2 non dovesse biforcare l'intera DLL Cygwin; apparentemente quelle discussioni non sono andate lontano. Mentre MSYS2 ha energia ora, lo prevedo stagnante come MSYS se / quando i volontari MSYS2 smettono di aggiornarlo
—
James Johnston,
@JamesJohnston Penso che potresti essere in grado di ottenere risposte migliori alle tue domande sul canale IRC menzionato da Ray nella sua risposta. Questa catena di commenti sta diventando piuttosto lunga e deviata dall'argomento.
—
jpmc26,
