it-swarm.com.de

Warum gibt es keine Paketverwaltungssysteme für C und C ++?

Es gibt einige Programmiersprachen, für die es ein Paketverwaltungssystem gibt:

Gibt es andere Sprachen mit solchen Systemen? Was ist mit C und C++? (das ist die Hauptfrage!) Warum gibt es für sie keine solchen Systeme? Und erstellt keine Pakete für yum, apt-get oder andere allgemeine Paketverwaltungssysteme besser?

82
m0nhawk

Tatsächlich arbeiten einige Leute (von spürbarem Ruhm) hart daran, ein solches System namens Ryppl zu schaffen und zu etablieren. Es ist schwierig, ein solches System für C++ einzurichten, da es keinen einzelnen Spieler gibt, der es diktieren kann. --UPDATE: Leider wird es aufgegeben.

Bei Ihrer zweiten Frage geht ein normaler Paketmanager (abgesehen davon, dass er nicht plattformübergreifend ist) nicht auf die spezifischen Anforderungen von Entwicklern ein.

31
Fabio Fracassi

Ich denke, dass ein Problem mit C und noch mehr mit C++ darin besteht, dass es sich um heterogenere Sprachen handelt: Obwohl diese Sprachen standardisiert sind, gibt es verschiedene Compiler mit unterschiedlichen Optionen oder unterschiedlichen Sätzen unterstützter Funktionen. Ich erinnere mich beispielsweise, dass ich eine Frage zu C++ beim Stapelüberlauf mit einem Beispiel gepostet habe, das unter GCC/Linux perfekt funktioniert hat, und jemand hat sofort eine Antwort gepostet, dass mein Code nicht dem Standard entspricht.

Ein Paketsystem wie das in der Frage erwähnte würde bedeuten, eine gemeinsame Sprache und Bibliotheken zu haben, die von allen wichtigen Compilern auf allen gängigen Betriebssystemen einheitlich unterstützt werden. Sie möchten beispielsweise kein C++ - Paket herunterladen und feststellen, dass es auf Ihrer Version von Compiler X nicht kompiliert werden kann, da es auf Compiler Y unter einem anderen Betriebssystem entwickelt wurde.

Ich könnte mir vorstellen, dass ein System, das auf Make- und Configure-Skripten basiert (wie es üblicherweise unter Linux, Cygwin und anderen Unix-Varianten zu finden ist), funktionieren könnte. Aber warum sollten Visual Studio-Benutzer es übernehmen? Gleiches gilt, wenn ein Paketsystem auf Basis von Microsoft Compilern (und Bibliotheken) gestartet wurde.

Die Tatsache, dass C++ eine sich schnell entwickelnde Sprache ist und ihre Standards immer einige Zeit in Anspruch nehmen, bevor sie von allen Compilern vollständig unterstützt werden, lindert das Problem nicht.

17
Giorgio

Ich denke, die Fragen, die wir stellen müssen, um Ihre zu beantworten, lauten: "Was profitieren andere Sprachen/Ökosysteme von einem eigenen zentralen Paket-Repository?" und "Gilt das für C/C++?"

Ich bin der Meinung, dass die Antwort auf die erste Frage etwas mit der anfänglichen Förderung einer neuen Sprache zu tun hat: Die Early Adopters möchten es Neulingen so einfach wie möglich machen, in das Ökosystem einzutreten, nützlichen, getesteten Code zu erwerben und ihren eigenen Beitrag zu leisten. Aus offensichtlichen Gründen hat das "Verwendungsdiagramm" immer eine einzige Wurzel - den/die Ersteller der Sprache. Normalerweise gibt es eine Referenzimplementierung (zumindest anfangs), und daher muss jeder Code, den Sie freigeben möchten, dieser entsprechen.

Dies macht es einfach, Pakete zu erstellen, die nur heruntergeladen und kompiliert werden. Wäre C oder C++ 2013 eingeführt worden, hätten ihre Communities sicherlich einen ähnlichen Entwicklungspfad verfolgen können, aber dies war nicht der Fall, und es gibt keine einzige vorherrschende Toolchain, auf die ein Paketmanager angewendet werden könnte. Dies macht die Implementierung eines solchen Programms zu mühsam, um den Aufwand wert zu sein. (Sollten Sie Benutzer dazu bringen, zwischen libfoo-gcc und libfoo-vs zu wählen? Überlassen Sie die Lösung dem Packager? Oder dem Erstellungsprozess? Wenn ja, wie unterscheidet sich ein Paket von einem direkten Tarball?)

Um meine Antwort auf die erste Frage zusammenzufassen: Ich denke, das Muster beim Erstellen von Paketmanagern dient hauptsächlich dazu, Annahme voranzutreiben.

Vor diesem Hintergrund denke ich, dass es ziemlich leicht zu erkennen ist, warum kein einzelnes System gestiegen ist, um diesen Bedarf zu decken - da der Bedarf für C- und C++ - Programmierer nicht besteht. Was für die C- und C++ - Community (oder wirklich jede Programmierer-Community) ein Problem darstellt, ist die ursprünglich implizierte Notwendigkeit: Code zu verteilen, auf dem neuesten Stand zu halten und zurückzugeben. Dies wurde viele Male von verschiedenen Personen mit unterschiedlichem Erfolg gelöst, und tatsächlich gewinnt ein System einen bedeutenden Marktanteil: git (und einige andere Systeme davor).

Grundsätzlich, wenn die Probleme unterschiedlich sind, sehen die Lösungen auch anders aus, aber IMHO der Unterschied zwischen der Eingabe von gem install und git clone ist strittig.

4
idoby

Diese Frage ist etwas verwirrend. Die oben genannte Software verwaltet Erweiterungen für bestimmte Programmiersprachen. Sie bieten Bibliotheken und Quellcode, die anschließend in Ihrem Programm mit der Programmiersprache Ihrer Wahl verwendet werden können.

Während allgemeine Paketmanager auf Systemebene normalerweise Binärpakete bereitstellen, die unabhängig von der Anwendung verwendet werden können. Sie sind stärker auf das System und den Benutzer ausgerichtet. Natürlich können Paketverwaltungssysteme auf Systemebene wie Aptitude, rpm, Entropy beliebige Pakete bereitstellen, sei es Binär- oder Quellcode. Aus diesem Grund finden Sie in ihnen die meisten Erweiterungen, die Sie beispielsweise mit ... Gem installieren würden.

Dann sind das, was Sie als Yum und Apt-get oder Rigo erwähnt haben nur Benutzeroberflächen für die darunter liegenden Paketverwaltungssysteme.

Noch eine für die Liste der Programmiersprachen:

  • Komponist und Birne für PHP
3
Patkos Csaba

Mir ist klar, dass dies keine plattformübergreifende Lösung ist, aber sie sollte dem Mix hinzugefügt werden.

CoApp hat kürzlich die Unterstützung für die C++ - Paketverwaltung mit NuGet angekündigt: http://blog.nuget.org/20130426/native-support.html

Dies funktioniert derzeit nur mit dem Visual Studio-Compiler, es gab jedoch viele Anfragen, dies auf anderen Plattformen zum Laufen zu bringen.

0
Joe