Perché non ci sono sistemi di gestione dei pacchetti per C e C ++? [chiuso]

In realtà alcune persone (di notevole notorietà) stanno lavorando duramente per creare e stabilire un sistema chiamato Ryppl . È difficile stabilire un tale sistema per C ++, perché non ha un singolo giocatore che può dettarlo. --UPDATE: Purtroppo è abbandonato.

Sulla seconda domanda, un normale gestore di pacchetti (oltre a non essere multipiattaforma) non gestisce le esigenze specifiche degli sviluppatori.

Penso che un problema con C e ancora di più con C ++ sia che sono linguaggi più eterogenei: anche se questi linguaggi sono standardizzati, esistono diversi compilatori con diverse opzioni o diversi set di funzionalità supportate. Ad esempio, ricordo di aver postato una domanda su C ++ sullo stack overflow con un esempio che funzionava perfettamente su GCC / Linux e qualcuno ha immediatamente postato una risposta dicendo che il mio codice era non standard.

Avere un sistema di pacchetti come quelli menzionati nella domanda implicherebbe avere un linguaggio e librerie comuni supportati in modo uniforme da tutti i principali compilatori su tutti i sistemi operativi comuni. Ad esempio, non vuoi scaricare un pacchetto C ++ e scoprire che non verrà compilato sulla tua versione del compilatore X perché è stato sviluppato sul compilatore Y su un altro sistema operativo.

Potrei immaginare che un sistema basato su make e configure scripts (come si trovano comunemente su Linux, cygwin e altri sapori Unix) possa funzionare. Ma perché gli utenti di Visual Studio dovrebbero adottarlo? Lo stesso è valido se si è avviato un sistema di pacchetti basato su Microsoft Compilers (e librerie).

Il fatto che C ++ sia un linguaggio in rapida evoluzione e i suoi standard richiedono sempre del tempo prima di essere pienamente supportati da tutti i compilatori non allevia il problema.

Penso che le domande che dobbiamo porre per rispondere alle tue siano "Cosa guadagnano gli altri linguaggi / ecosistemi dall'avere il proprio repository di pacchetti centralizzato?" e "Questo vale per C / C ++?"

Sento che la risposta alla prima domanda ha qualcosa a che fare con la promozione iniziale di una nuova lingua: gli early adopter vogliono rendere il più semplice possibile per i nuovi arrivati entrare nell'ecosistema, acquisire codice utile e testato e contribuire il loro. Per ovvi motivi, il "grafico di utilizzo" ha sempre una singola radice - il creatore (i) della lingua. Di solito c'è un'implementazione di riferimento (almeno inizialmente) e quindi qualsiasi codice che potresti voler condividere deve conformarsi ad esso.

Ciò semplifica la creazione di pacchetti che vengono semplicemente scaricati e compilati. Certamente, se nel 2013 fosse stato introdotto C o C ++, le loro comunità avrebbero potuto seguire un percorso evolutivo simile, ma non l'hanno fatto e non esiste una sola toolchain prevalente per applicare un gestore di pacchetti. Ciò rende l'implementazione di un programma di questo tipo troppo problematico per valerne la pena. (dovresti fare in modo che gli utenti scelgano tra libfoo-gcc e libfoo-vs? Lascialo al packager da risolvere? O al processo di compilazione? Se sì, in che modo un pacchetto è diverso da un tarball diretto?)

Quindi, per riassumere la mia risposta alla prima domanda, penso che lo schema di creazione dei gestori di pacchetti serva principalmente a guidare l'adozione .

Con questo in mente, penso che sia abbastanza facile capire perché nessun singolo sistema è cresciuto per soddisfare questa necessità - perché non esiste la necessità per i programmatori C e C ++. Ciò che costituisce un problema per la comunità C e C ++ (o qualsiasi comunità di programmatori, in realtà) è la necessità implicita in origine: distribuire, tenere aggiornato e fornire il codice di ritorno. Questo problema è stato risolto molte volte da persone diverse con diversi gradi di successo, e in effetti un sistema sta guadagnando una quota di mercato significativa: git (e alcuni altri sistemi prima).

Fondamentalmente quando i problemi sono diversi, anche le soluzioni sembrano diverse, ma IMHO la differenza tra digitare gem install e git clone è moot.

C'è una piccola confusione in questa domanda. Il software sopra menzionato gestisce le estensioni per specifici linguaggi di programmazione. Forniscono librerie e codice sorgente che successivamente possono essere utilizzati nel tuo programma con il linguaggio di programmazione prescelto.

Mentre i gestori di pacchetti a livello di sistema generale di solito forniscono pacchetti binari che possono essere utilizzati indipendentemente dall'applicazione. Sono più orientati al sistema e all'utente. Naturalmente, i sistemi di gestione dei pacchetti a livello di sistema come Aptitude, rpm, Entropy possono fornire qualsiasi pacchetto , essendo codice binario o sorgente. Ecco perché troverai la maggior parte delle estensioni che installeresti con ... Gem per esempio.

Than, ciò che hai citato come Yum e Apt-get o Rigo sono solo interfacce utente per i sistemi di gestione dei pacchetti sottostanti.

Un altro per l'elenco o i linguaggi di programmazione:

• Composer and Pear per PHP

Mi rendo conto che questa non è una soluzione multipiattaforma, ma dovrebbe essere aggiunta al mix.

CoApp ha recentemente annunciato il supporto per la gestione dei pacchetti C ++ utilizzando NuGet: link

Attualmente funziona solo con il compilatore di Visual Studio, ma ci sono state molte richieste per farlo funzionare su altre piattaforme.