Cómo administrar bibliotecas de terceros en un proyecto de configuration múltiple

Supongamos que está trabajando en algún proyecto que admite varias configuraciones (construcciones de Linux y Windows, enlaces compartidos / estáticos, con alguna característica o sin ella, etc.). Para build todas estas configuraciones necesita diferentes versiones de componentes de terceros (construidos con gcc o msvc, shanetworking / static, con algunas definiciones de preprocesador especificadas, etc.). Así que eventualmente terminas con el problema de administrar todas estas configuraciones no solo para tu proyecto, sino también para todas las bibliotecas que tu proyecto está usando.

¿Existe una solución / enfoque / software general para facilitar la administración de varias configuraciones diferentes de un solo proyecto?

Criterios :

  • Facilidad de configuration, es decir, ¿cuánto time uno necesitaría gastar para build su proyecto desde cero?
  • La facilidad de gestión, es decir, ¿es difícil agregar una nueva dependencia o eliminar una existente?
  • Prueba de errores, es decir, ¿con qué frecuencia los desarrolladores romperán la construcción al cambiar las dependencies?

Hasta ahora he intentado varios enfoques.

  1. Almacene packages preconstruidos para cada configuration en VCS.

    Pros : Facilidad de configuration cuando el proyecto es pequeño (actualice la copy de trabajo y estará listo para comenzar). Facilidad de administración (biblioteca de compilation una vez para cada configuration requerida). Prueba de error (el cliente de VCS le notifica acerca de los cambios en su copy de trabajo).

    Contras : no funciona bien para VCS distribuidos (GIT, Mercurial, etc.). El repository crece rápidamente y eventualmente una simple operación de "clonación" será intolerable. También terminas descargando muchas cosas que realmente no necesitas (es decir, librerías de Windows si estás trabajando en Linux). Y si está implementando la biblioteca, los usuarios de su biblioteca henetworkingarán todos estos problemas integrándolos en su proyecto.

  2. Almacenar fonts de la biblioteca en lugar de packages preconstruidos.

    Pros : Facilidad de configuration.

    Contras : es extremadamente doloroso agregar una nueva biblioteca. Debe proporcionar scripts de compilation y parches de origen para cada configuration. Pero eso es solo la punta del iceberg. Tus dependencies tienen sus propias dependencies, que tienen las suyas propias, etc., etc. Tienes buenas posibilidades de terminar con algo así como una distribución de Gentoo 🙂

  3. Almacene un file o solo una carpeta con packages preconstruidos en algún lugar del server externo.

    Pros : Resuelve el problema … más o less.

    Contras : No es tan fácil de configurar (tiene que copyr el file manualmente). No es tan fácil de administrar (tiene que agregar cada biblioteca a un server a mano). Sin historial de cambios. No es a testing de errores, porque es fácil olvidarse de poner algo en el server o eliminar algo útil.

    Un enfoque ligeramente mejorado: puede usar un VCS centralizado (por ejemplo, SVN) para almacenar todas las bibliotecas de terceros, será más fácil trabajar con él. Pero todavía no tienes un historial centralizado de cambios si lo usas como un simple almacenamiento de files, o si obtienes un enorme repository con muchas librerías innecesarias si lo usas como un sub-repository.

Cuando se enfrenta a este tipo de problemas, debe aprender y comenzar a utilizar las herramientas de gestión de configuration (además de las técnicas habituales de su SCM de elección). CM es un process , y el uso de algunas de las herramientas de administración de la configuration es parte de este process.

Actualmente tenemos una gran selección de diferentes herramientas CM, en las que puede seleccionar el mejor ajuste o simplemente preferido. Desde mi punto de vista, el chef es "la mejor opción para todos", su kilometraje puede variar