¿Por qué no hay sistemas de gestión de paquetes para C y C ++? [cerrado]

Existen algunos lenguajes de programación para los que existe un sistema de gestión de paquetes:

• CTAN para TeX
• CPAN para Perl
• Pip & Eggs for Python
• Maven para Java
• cabal para Haskell
• Gemas para Ruby
• npm para NodeJS
• Bower para frontend Javascript y CSS
• nuget para C #
• compositor para PHP

¿Hay otros idiomas con tales sistemas? ¿Qué pasa con C y C ++? (¡esa es la pregunta principal!) ¿Por qué no hay tales sistemas para ellos? Y no es la creación de paquetes para yum, apt-getu otros sistemas generales de gestión paquete mejores?

En realidad, algunas personas (de notable fama de impulso) están trabajando duro para crear y establecer un sistema llamado Ryppl . Es difícil establecer dicho sistema para C ++, porque no tiene un solo jugador que pueda dictarlo. - ACTUALIZACIÓN: Lamentablemente se abandona.

En su segunda pregunta, un administrador de paquetes normal (además de no ser multiplataforma) no maneja las necesidades específicas de los desarrolladores.

Creo que un problema con C y aún más con C ++ es que son lenguajes más heterogéneos: aunque estos lenguajes están estandarizados, existen diferentes compiladores con diferentes opciones o diferentes conjuntos de características compatibles. Por ejemplo, recuerdo haber publicado una pregunta sobre C ++ en el desbordamiento de pila con un ejemplo que funcionaba perfectamente en GCC / Linux y alguien inmediatamente publicó una respuesta diciendo que mi código no era estándar.

Tener un sistema de paquetes como los mencionados en la pregunta implicaría tener un lenguaje común y bibliotecas compatibles con todos los compiladores principales en todos los sistemas operativos comunes. Por ejemplo, no desea descargar un paquete C ++ y descubrir que no se compilará en su versión del compilador X porque se desarrolló en el compilador Y en otro sistema operativo.

Me imagino que un sistema basado en crear y configurar scripts (como se encuentra comúnmente en Linux, Cygwin y otros sabores de Unix) podría funcionar. Pero, ¿por qué los usuarios de Visual Studio deberían adoptarlo? Lo mismo es válido si uno inició un sistema de paquetes basado en compiladores de Microsoft (y bibliotecas).

El hecho de que C ++ sea un lenguaje en rápida evolución y sus estándares siempre demoren un tiempo antes de que todos los compiladores lo admitan por completo no alivia el problema.

Creo que las preguntas que debemos hacer para responder a las suyas son "¿Qué ganan otros lenguajes / ecosistemas al tener su propio repositorio centralizado de paquetes?" y "¿Se aplica esto a C / C ++?"

Creo que la respuesta a la primera pregunta tiene algo que ver con la promoción inicial de un nuevo lenguaje: los primeros usuarios quieren que sea lo más fácil posible para los recién llegados ingresar al ecosistema, adquirir código útil y probado y contribuir de nuevo. Por razones obvias, el "gráfico de uso" siempre tiene una única raíz: los creadores del idioma. Por lo general, hay una implementación de referencia (al menos inicialmente) y, por lo tanto, cualquier código que desee compartir debe ajustarse a ella.

Esto facilita la creación de paquetes que solo se descargan y compilan. Ciertamente, si C o C ++ se introdujeran en 2013, sus comunidades podrían haber seguido un camino evolutivo similar, pero no lo hicieron y no hay una única cadena de herramientas predominante para aplicar un administrador de paquetes. Esto hace que la implementación de dicho programa sea demasiado problemática para que valga la pena. (¿Debería hacer que los usuarios elijan entre libfoo-gcc y libfoo-vs? ¿Deja que el empaquetador lo resuelva? ¿O el proceso de compilación? Si es así, ¿en qué se diferencia un paquete de un tarball directo?)

Entonces, para resumir mi respuesta a la primera pregunta, creo que el patrón de crear administradores de paquetes sirve principalmente para impulsar la adopción .

Con eso en mente, creo que es bastante fácil ver por qué ningún sistema único ha surgido para satisfacer esta necesidad, porque la necesidad no existe para los programadores C y C ++. Lo que sí constituye un problema para la comunidad C y C ++ (o cualquier comunidad de programadores, en realidad) es la necesidad originalmente implicada: distribuir, mantenerse actualizado y contribuir con el código. Esto ha sido resuelto muchas veces por diferentes personas con diferentes grados de éxito, y de hecho, un sistema está ganando una importante cuota de mercado: git (y algunos otros sistemas antes de eso).

Básicamente, cuando los problemas difieren, las soluciones también se ven diferentes, pero en mi humilde opinión, la diferencia entre escribir gem instally git clonees discutible.

Hay una pequeña confusión en esta pregunta. El software mencionado anteriormente administra extensiones para lenguajes de programación específicos. Proporcionan bibliotecas y código fuente que luego se pueden usar en su programa con el lenguaje de programación de su elección.

Mientras que los administradores de paquetes de nivel general del sistema generalmente proporcionan paquetes binarios que se pueden usar independientemente de la aplicación. Están más orientados al sistema y al usuario. Por supuesto, los sistemas de gestión de paquetes a nivel de sistema como Aptitude, rpm, Entropy pueden proporcionar cualquier paquete, ya sea binario o código fuente. Es por eso que encontrarás en ellas la mayoría de las extensiones que instalarías con ... Gem, por ejemplo.

Entonces, lo que mencionó como Yum y Apt-get o Rigo son solo interfaces de usuario para los sistemas de administración de paquetes que se encuentran debajo de ellos.

Uno más para la lista de lenguajes de programación:

• Compositor y Pera para PHP

Me doy cuenta de que esta no es una solución multiplataforma, pero debe agregarse a la mezcla.

CoApp anunció recientemente soporte para la administración de paquetes C ++ usando NuGet: http://blog.nuget.org/20130426/native-support.html

Actualmente, esto solo funciona con el compilador de Visual Studio, pero ha habido muchas solicitudes para que esto funcione en otras plataformas.