Uso de Makefile en lugar de archivos de solución/proyecto en Visual Studio (2005)

Question

¿Alguien tiene experiencia en el uso de archivos MAKE para compilaciones de Visual Studio C++ (bajo VS 2005) en lugar de usar la configuración del proyecto/solución?Para nosotros, la forma en que funcionan el proyecto/soluciones no es intuitiva y conduce a una explosión de configuración cuando se intenta modificar compilaciones con indicadores de tiempo de compilación específicos.

En Unix, es bastante fácil configurar un archivo MAKE cuyas opciones predeterminadas sean anuladas por la configuración del usuario (u otra configuración).Pero hacer este tipo de cosas parece difícil en Visual Studio.

A modo de ejemplo, tenemos un proyecto que necesita construirse para 3 plataformas diferentes.Cada plataforma puede tener varias configuraciones (por ejemplo, depuración, lanzamiento y varias otras).Uno de mis objetivos en un proyecto recién creado es tener una solución que pueda hacer que todas las plataformas convivan juntas, lo que facilita la creación y prueba de cambios de código, ya que no es necesario abrir 3 soluciones diferentes solo para probar el código.Pero Visual Studio requerirá configuraciones 3 * (número de configuraciones base).es decir.Depuración de PC, depuración de X360, depuración de PS3, etc.

Parece que una solución de archivo MAKE es mucho mejor aquí.Envuelto con algunos archivos por lotes o scripts básicos, sería fácil mantener la explosión de configuración al mínimo y solo mantener un pequeño conjunto de archivos para todas las diferentes compilaciones que tenemos que hacer.

Sin embargo, no tengo experiencia con archivos MAKE en Visual Studio y me gustaría saber si otras personas tienen experiencias o problemas que puedan compartir.

Gracias.

(publicación editada para mencionar que estas son compilaciones de C++)

Answer 1

He encontrado algunos beneficios para los archivos MAKE con proyectos grandes, principalmente relacionados con unificar la ubicación de la configuración del proyecto.Es algo más fácil administrar la lista de archivos fuente, incluir rutas, definiciones de preprocesador, etc., si todos están en un archivo MAKE u otro archivo de configuración de compilación.Con múltiples configuraciones, agregar una ruta de inclusión significa que debe asegurarse de actualizar cada configuración manualmente a través de las complicadas propiedades del proyecto de Visual Studio, lo que puede volverse bastante tedioso a medida que un proyecto crece en tamaño.

Los proyectos que utilizan muchas herramientas de compilación personalizadas también pueden ser más fáciles de administrar, por ejemplo, si necesita compilar sombreadores de píxeles/vértices o codificar en otros lenguajes sin soporte VS nativo.

Sin embargo, aún necesitarás tener varias configuraciones de proyecto diferentes, ya que necesitarás diferenciar la invocación de la herramienta de compilación para cada configuración (p. ej.pasando diferentes opciones de línea de comando para crear).

Desventajas inmediatas que me vienen a la mente:

• Construcciones más lentas:VS no es particularmente rápido a la hora de invocar herramientas externas, ni siquiera de determinar si necesita construir un proyecto en primer lugar.
• Dependencias incómodas entre proyectos:Es complicado configurarlo para que una dependencia haga que se construya el proyecto base, y más complicado asegurarse de que se construya en el orden correcto.He tenido cierto éxito al lograr que SCons hiciera esto, pero siempre es un desafío lograr que funcione bien.
• Pérdida de algunas características útiles del IDE:¡Edita y continúa siendo el principal!

En resumen, dedicará menos tiempo a administrar las configuraciones de su proyecto, pero más tiempo a convencer a Visual Studio para que funcione correctamente con él.

Answer 2

Visual Studio se está construyendo sobre el MSBuild archivos de configuración.Puede considerar los archivos *proj y *sln como archivos MAKE.Le permiten personalizar completamente el proceso de construcción.

Answer 3

Si bien es técnicamente posible, no es una solución muy amigable dentro de Visual Studio.Estará luchando contra ti todo el tiempo.

Te recomiendo que eches un vistazo hormiga.Es un sistema de construcción muy robusto donde puedes hacer básicamente cualquier cosa que necesites.

Nuestro script NAnt hace esto en cada compilación:

1. Migrar la base de datos a la última versión.
2. Generar entidades C# fuera de la base de datos
3. Compile cada proyecto en nuestra solución "maestra"
4. Ejecute todas las pruebas unitarias
5. Ejecute todas las pruebas de integración

Además, nuestro servidor de compilación aprovecha esto y agrega una tarea más, que es generar documentación de Sandcastle.

Si no te gusta XML, también puedes echar un vistazo a Rastrillo (rubí), Hornear/BooBuildSystem (Abucheo), o Psake (Potencia Shell)

Answer 4

Puede usar nant para construir los proyectos individualmente, reemplazando así la solución y tener 1 solución de codificación y ninguna solución de compilación.

Una cosa a tener en cuenta es que la solución y los archivos csproj de 2005 en adelante son scripts msbuild.Entonces, si se familiariza con msbuild, es posible que pueda utilizar los archivos existentes para facilitar la comparación y facilitar su implementación.

Answer 5

Tenemos una configuración similar a la que estás describiendo.Admitimos al menos 3 plataformas diferentes, por lo que descubrimos que usar Chacer para gestionar las diferentes soluciones de Visual Studio.La configuración puede ser un poco dolorosa, pero se reduce básicamente a leer los documentos y un par de tutoriales.Debería poder hacer prácticamente todo lo que puede hacer yendo a las propiedades de los proyectos y la solución.No estoy seguro de si puede hacer que las tres plataformas convivan juntas en la misma solución, pero puede usar Control de crucero para cuidar sus compilaciones y ejecutar sus scripts de prueba con tanta frecuencia como sea necesario.