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

En realidad, algunas personas (con un notable aumento de la fama) están trabajando arduamente para crear y establecer un sistema llamado Ryppl . Es difícil establecer un Sistema de este tipo para C ++, porque no tiene un solo jugador que pueda dictarlo. - ACTUALIZAR: Desafortunadamente 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 estaba funcionando 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 que sean compatibles de manera uniforme por todos los compiladores principales en todos los sistemas operativos comunes. Por ejemplo, no desea descargar un paquete de 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.

Podría imaginar que un sistema basado en la creación y configuración de scripts (como se encuentra comúnmente en Linux, cygwin y otros tipos de Unix) podría funcionar. Pero, ¿por qué deberían los usuarios de Visual Studio 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 de rápida evolución y sus estándares siempre tarde algún tiempo antes de ser totalmente compatible con todos los compiladores no soluciona el problema.

Creo que las preguntas que debemos formular para responder a las suyas son "¿Qué ganan otros idiomas / ecosistemas al tener su propio repositorio de paquetes centralizado?" 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 idioma: los primeros usuarios quieren facilitar que los nuevos usuarios ingresen al ecosistema, adquieran códigos útiles y probados y contribuyan con la devolución. su propia Por razones obvias, el "gráfico de uso" siempre tiene una sola raíz: el / los creador (es) del lenguaje. Por lo general, hay una implementación de referencia (al menos inicialmente) y, por lo tanto, cualquier código que quieras compartir tiene que ajustarse a ella.

Esto facilita la creación de paquetes que solo se descargan y compilan. Ciertamente, si se hubiera introducido C o C ++ 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 tal programa sea demasiado problemática para que valga la pena la molestia. (¿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?)

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

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

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

Hay un poco de confusión en esta pregunta. El software mencionado anteriormente gestiona las 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 que elija.

Mientras que los gestores generales de paquetes a nivel del sistema generalmente proporcionan paquetes binarios que pueden usarse 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á en ellas la mayoría de las extensiones que instalaría con ... Gem por ejemplo.

Lo que mencionaste como Yum y Apt-get o Rigo son solo interfaces de usuario para los sistemas de administración de paquetes debajo de ellos.

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

• Compositor y Pear para PHP

Me doy cuenta de que esta no es una solución multiplataforma, pero debería agregarse a la combinación.

CoApp anunció recientemente el soporte para la gestión de paquetes C ++ utilizando NuGet: enlace

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