No conozco ninguna solución general bajo las limitaciones dadas: específicamente tener que crear muchos proyectos desde un árbol fuente.
La mejor opción que veo es en realidad la creación de los archivos del proyecto por algún script.
- Creación de un solo proyecto manualmente (crear proyecto vacío, a continuación, añadir los archivos),
- Configurar que lo más cerca posible a su gusto (es decir, con los encabezados precompilados, crear configuraciones, etc.)
- uso del .vcproj creado como esqueleto para crear los archivos del proyecto
Un método muy simple sería la lista de archivos, el nombre del proyecto, etc. con "tokens extraños", y rellenarlos con su generador. Si quieres ser el chico bueno, puedes usar una biblioteca de manejo de XML.
Nuestra experiencia: En realidad no almacenamos la .vcproj y .sln en el repositorio (GIT) más, pero un script en Python que re-genrates ellos desde el árbol de código fuente, junto con VS 2008 "plantillas de hojas de propiedades" (o como se llamen). Esto ayuda mucho a hacer ajustes generales.
script de generación de
El proyecto contiene información sobre todos los proyectos de especialidades (por ejemplo, qué utilizan MFC/ATL, va a crear DLL o un EXE, archivos para excluir).
Además, este script también contiene dependencias, que alimenta el script de compilación real.
Esto funciona bastante bien, los problemas son menores: se necesita Python en los sistemas de compilación, sin olvidar volver a generar los archivos del proyecto, tengo que aprender algo de Python para hacer ajustes en algunos proyectos.
@ Michael Burr "¿Qué tan complejo son los scripts de Python y lo apoyan 'plantillas' que pueda necesitar?"
Honestamente, no puedo decirlo, ya que le di la tarea a otro desarrollador (que eligió Python). La tarea original era proporcionar un script de compilación, ya que la compilación de la solución VS2008 no era lo suficientemente buena para nuestras necesidades, y el archivo de proceso por lotes anterior no era compatible con la paralelización. .vcproj generación se agregó más tarde. Según tengo entendido, su script genera los archivos .vcproj y .sln desde cero, pero extrae todas las configuraciones de las hojas de propiedades separadas.
Pros:
Adición de nuevas configuraciones sobre la marcha. Algunos de los proyectos ya tenían seis configuraciones, y la planificación del soporte Unicode significaba considerar doblarlos por un tiempo. Algunas herramientas incómodas todavía se construyen como MBCS, por lo que algunas bibliotecas tienen ahora 8 configuraciones. Configurar eso de la mano es un dolor, ahora ya no me molesta más.
Cambios globales, p. moviéndonos por las rutas relativas del proyecto, la carpeta de archivos temporales y los binarios finales hasta que encontramos una solución con la que estamos contentos con
Build Stability. La fusión de los archivos del proyecto VC6 fue una fuente notable de errores por varias razones, y los archivos del proyecto VC9 no se veían mejor. Ahora las cosas parecen estar mejor aisladas: configuración de compilación/enlace en las hojas de propiedades, manejo de archivos en el script. Además, la secuencia de comandos en su mayoría listas variaciones de nuestro predeterminado, terminando más fácil de leer que un archivo de proyecto.
general: no veo un gran beneficio cuando sus proyectos ya están configurados, son bastante estables, y que no tienen problemas reales. Sin embargo, al pasar al desconocido (para nosotros: principalmente compilaciones VC6 -> VC9 y Unicode), la flexibilidad redujo el riesgo de los experimentos en gran medida.
Esto me parece bastante interesante. ¿Qué tan complejas son las secuencias de comandos de Python y las "plantillas" de soporte que pueda necesitar? –