build automation - ¿Cómo organizar el árbol de proyecto para un proyecto de C++ usando nmake?

build-automation project-organization

Question

Parece haber dos convenciones principales para organizar los archivos de proyectos y luego muchas variaciones.

Convención 1: directorios de tipos de alto nivel, subdirectorios de proyectos

Por ejemplo, el proyecto wxWidgets usa este estilo:

/solution
   /bin
      /prj1
      /prj2
   /include
      /prj1
      /prj2
   /lib
      /prj1
      /prj2
   /src
      /prj1
      /prj2
   /test
      /prj1
      /prj2

Pros:

• Si hay dependencias de proyectos, se pueden gestionar desde un único archivo
• Estructura de archivo de compilación plana

Contras:

• Dado que la prueba tiene sus propios archivos de cabecera y cpp, cuando genera las aplicaciones de prueba unitaria para archivos EXE en lugar de bibliotecas, deben incluir los archivos de objetos de la aplicación que está probando. Esto requiere que cree reglas de inferencia y amplíe las rutas relativas para todos los archivos fuente.
• Reutilizar cualquiera de los proyectos en otra solución requiere que extraiga los archivos adecuados de la estructura de árbol y modifique los scripts de compilación.

Convención 2: directorios de proyectos de alto nivel, tipos de subdirectorios

Por ejemplo, el proyecto Wireshark usa este estilo

/solution
   /prj1
      /bin
      /include
      /lib
      /src
      /test
   /prj2
      /bin
      /include
      /lib
      /src
      /test

Pros:

• Los proyectos en sí mismos son independientes dentro de sus carpetas, lo que los hace más fáciles de mover y reutilizar
• Permite reglas de inferencia más cortas en las herramientas de compilación
• Facilita los scripts de compilación jerárquica

Contras:

• Si hay dependencias entre proyectos, necesita una capa adicional de scripts de compilación sobre los directorios del proyecto para administrar el orden de compilación.

Actualmente estamos usando la convención 1 en nuestro proyecto y hasta ahora ha funcionado bastante bien. Ahora, estoy en el proceso de agregar pruebas unitarias (a través de CxxTest) y facilitar la migración a la integración continua usando nmake , la convención 1 está causando serios problemas en la creación de los archivos nmake adecuados.

Mis requisitos / objetivos principales son:

• Reduzca el nivel de esfuerzo para mantener los scripts de compilación de toda la solución.

• Desvincular los proyectos y sus pasos de construcción dentro de una solución de otros proyectos.

• Facilite la integración continua a través del uso de scripts de compilación para el check-out para liberar la generación de medios para cada confirmación (obviamente aprovechando otras herramientas como CruiseControl también).

• Haga que añadir o eliminar proyectos adicionales o archivos fuente sea lo más fácil y menos propenso a errores posible para los desarrolladores.

Entonces pregunto:

• ¿Hay otros pros y contras de cualquiera de estos métodos?
• ¿Existe una agrupación clara que favorezca solo una de estas convenciones?

Answer 1

Considere el uso de puntos de unión NTFS para que pueda tener ambas organizaciones a la vez. Definición rápida: "un punto de unión es la implementación de Microsoft de enlaces simbólicos, pero solo funciona para directorios".

Utilice la Convención 2 para el diseño "real", ya que facilita el desplazamiento de los proyectos. Luego haga una vista de Convención 1:

mkdir /solution/test
linkd /solution/test/prj1 /solution/prj1/test
linkd /solution/test/prj2 /solution/prj2/test

Ahora tu tienes ...

/solution
  /test
    /prj1
    /prj2 

... que fue el resultado deseado.

Podría hacer lo mismo para / src o para los otros directorios si lo encuentra beneficioso. Guiones de prueba que se benefician de una vista de Convención 1 en vivo en / solución / prueba.

Answer 2

[Una respuesta parcial.]

En "Convención 2: directorios de proyectos de alto nivel, escriba subdirectorios," su única estafa es

Si hay dependencias entre proyectos, necesita una capa adicional de scripts de compilación sobre los directorios del proyecto para administrar el orden de compilación.

Eso también se puede ver como un profesional en muchos proyectos.

Si tiene muchas definiciones generales repetitivas, es probable que desee un archivo de inclusión para los scripts de compilación, donde podrían definirse las constantes y los parámetros de toda la solución. Por lo tanto, la "capa adicional de scripts de compilación" ocurrirá con frecuencia de todos modos, incluso si no hay dependencias (directas).

Es un profesional en que aún hay espacio para un enfoque más modular en la construcción. Por otro lado, si desea reutilizar un proyecto en otra solución no relacionada, deberá componer un archivo de definiciones diferente. (Por otro lado, si hubiera un único archivo de compilación para toda la solución, como en la Convención 1, necesitaría una secuencia de comandos de compilación diferente). En cuanto a sus requisitos de mantenimiento, eso es (IMO) muy dependiente del proyecto.

Mi sentimiento se inclina hacia la Convención 2, pero está lejos de ser una clara victoria. De hecho, su experiencia con la Convención 1, que funcionó bien hasta hace poco, puede ser la más importante de todas: un equipo de personas con experiencia en una determinada organización es un activo valioso.