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

Esistono alcuni linguaggi di programmazione per i quali esiste un sistema di gestione dei pacchetti:

• CTAN per TeX
• CPAN per Perl
• Pip e uova per Python
• Maven per Java
• cabala per Haskell
• Gemme per Ruby
• npm per NodeJS
• bower per frontend Javascript e CSS
• nuget per C #
• compositore per PHP

Esistono altre lingue con tali sistemi? Che dire di C e C ++? (Questa è la domanda principale!) Perché non ci sono tali sistemi per loro? E non è la creazione di pacchetti per yum, apt-geto altri sistemi di gestione generale pacchetto migliore?

In realtà alcune persone (di notevole notorietà) stanno lavorando duramente per creare e stabilire un tale sistema chiamato Ryppl . È difficile stabilire un tale sistema per C ++, perché non ha un singolo giocatore in grado di dettarlo. - AGGIORNAMENTO: purtroppo è stato abbandonato.

Sulla tua 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 sul C ++ in overflow dello stack con un esempio che funzionava perfettamente su GCC / Linux e qualcuno ha immediatamente inviato una risposta dicendo che il mio codice non era standard.

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

Potrei immaginare che un sistema basato su script di creazione e configurazione (come si trovano comunemente su Linux, Cygwin e altre versioni Unix) potrebbe funzionare. Ma perché gli utenti di Visual Studio dovrebbero adottarlo? Lo stesso vale se si avvia un sistema di pacchetti basato su Microsoft Compilers (e librerie).

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

Penso che le domande che dobbiamo porre per rispondere alle vostre siano "Che cosa guadagnano altre lingue / 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: i primi utenti vogliono rendere il più semplice possibile l'ingresso dei nuovi arrivati ​​nell'ecosistema, acquisire codice utile e testato e contribuire con il proprio. Per ovvie ragioni, il "grafico di utilizzo" ha sempre una sola radice: i creatori 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 possono essere scaricati e compilati. Certamente, se C o C ++ fossero stati introdotti nel 2013, le loro comunità avrebbero potuto seguire un percorso evolutivo simile, ma non lo erano e non esiste un unico toolchain prevalente a cui applicare un gestore di pacchetti. Ciò rende l'implementazione di tale programma troppo problematica per valere la seccatura. (dovresti fare in modo che gli utenti scelgano tra libfoo-gcc e libfoo-vs? Lo lasci al packager per risolvere? O il processo di compilazione? In tal caso, in che modo un pacchetto è diverso da un tarball semplice?)

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

Con questo in mente, penso che sia abbastanza facile capire perché nessun singolo sistema è cresciuto per soddisfare questa esigenza, perché la necessità non esiste 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à originariamente implicita: distribuire, tenersi aggiornati e contribuire con il back code. Ciò è stato risolto molte volte da persone diverse con vari gradi di successo, e in effetti un sistema sta guadagnando una significativa quota di mercato: git (e alcuni altri sistemi prima di quello).

Fondamentalmente quando i problemi differiscono, anche le soluzioni sembrano diverse, ma IMHO la differenza tra digitare gem installed git cloneè discutibile.

C'è un po 'di confusione in questa domanda. Il software sopra menzionato gestisce estensioni per linguaggi di programmazione specifici. Forniscono librerie e codice sorgente che in seguito possono essere utilizzati nel tuo programma con il tuo linguaggio di programmazione preferito.

Mentre i manger di pacchetti a livello di sistema generalmente 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, sia esso binario o codice sorgente. Ecco perché troverai in loro la maggior parte delle estensioni che installeresti con ... Gem per esempio.

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

Ancora uno per l'elenco dei linguaggi di programmazione:

• Compositore e Pera 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: http://blog.nuget.org/20130426/native-support.html

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