Cuando uno escribe un proyecto de código abierto y usa Google Code o GitHub, y quiere usar una biblioteca como Lua, ¿cómo debería hacerlo?
Dado que la biblioteca no necesita instalación antes de la compilación.
Respuestas:
Recomiendo leer la documentación de Git sobre submódulos ; aborda este mismo problema, suponiendo que todas sus fuentes usan Git. Si no lo hacen, siempre puede configurar un repositorio git con el propósito de integración. El esfuerzo es trivial y la recompensa es significativa.
¿Debería incluirse la dependencia en el repositorio?
Creo que las dependencias siempre deben incluirse en el repositorio siempre que su inclusión no viole los términos de uso. Pocas cosas son más molestas que tener que encontrar las versiones correctas de las dependencias correctas manualmente antes de poder hacer una compilación. Claro, esto es fácil cuando tienes herramientas automatizadas para hacer esto por ti, que pueden encontrar y descargar la dependencia correcta, pero qué pasa si no estás conectado a la web en este momento o si el servidor está caído o el proyecto de la dependencia ha sido descontinuado por completo y desconectado? Incluya siempre las dependencias si es posible.
¿Debería construirse la dependencia desde el mismo script de compilación que el resto del proyecto, o desde un script de compilación separado?
A menos que haya una buena razón para compilar desde la fuente, use versiones precompiladas.
¿Y por qué no proporcionar opciones en el script de compilación? Un simple cambio para elegir si las dependencias también deben compilarse o no. Si el usuario elige compilar también las dependencias, simplemente invoque sus propios scripts de compilación desde el script de compilación de su producto. Por lo tanto, el usuario puede invocar los scripts de compilación de las dependencias manualmente o elegir crear una compilación completa de todo. Pero solo entregaría las dependencias como archivos binarios si no hay una buena razón para compilarlas desde las fuentes. Creo que en el mundo del Código Abierto, algunas licencias requieren que distribuyas las fuentes junto con tu producto, pero eso no significa que no puedas tenerlas precompiladas.
En resumen: si es posible, proporcione un paquete de trabajo completo e independiente. Esto proporcionará la mayor comodidad a sus usuarios.
Esto puede o no aplicarse a su caso de uso, pero lo que hacemos en el trabajo es incluir una carpeta "Referencias" en cada rama. Colocamos archivos DLL de terceros aquí. Esto causa una gran cantidad de duplicación de archivos binarios relativamente inmutables en el control de código fuente, pero el almacenamiento es económico y en cualquier momento cada rama y etiqueta tiene exactamente las dependencias (¡y la versión!) Que espera.
Precompilamos las dependencias nosotros mismos y movemos los binarios compilados a esa carpeta. Nuestra propia biblioteca compartida interna también se trata de esta manera. De esa manera, la misma técnica funciona para bibliotecas propietarias precompiladas, bibliotecas de código abierto y bibliotecas internas.
En cuanto a responder realmente a su pregunta ahora que la he vuelto a leer, haga lo mismo y solo mencione que su proyecto utiliza una versión 1.3.5 precompilada de Lua.
¿Debería incluirse la dependencia en el repositorio?
Se puede hacer referencia en el repositorio (por cualquier método utilizable para SCM), si esta dependencia es parte integral del producto (dependencia de origen), no dependencia binaria, que se puede resolver por separado
¿Debería construirse la dependencia desde el mismo script de compilación que el resto del proyecto, o desde un script de compilación separado?
No importa en absoluto. Puede preferir cualquier método, de acuerdo con sus requisitos (velocidad / transparencia / capacidad de administración / etc.)
Al ser una tienda de Eclipse, acabamos de comenzar a usar Buckminster para administrar nuestro proceso de construcción / montaje / implementación.
Nuestra primera etapa ha sido sacar todas nuestras bibliotecas dependientes existentes y dejar que Buckminster se encargue de materializar las correctas. Esto permite una implementación mucho más rápida y pequeña.
El siguiente paso será mover nuestro svnrepositorio monolítico a una serie de gitrepositorios modulares .
No sé qué tan bien se integraría gitBuckminster con submódulos (o subrepos mercuriales para el caso), pero es bueno que Buckminster sea agnóstico con respecto al VCS utilizado para cualquier componente dado.