Tenemos un gran número de bibliotecas del núcleo y las aplicaciones basadas en esas bibliotecas. Mantenemos un sistema de compilación basado en Makefile en Linux y en Windows utilizando la solución de Visual Studio para cada proyecto o biblioteca.
Encontramos que funciona bien para nuestras necesidades, cada biblioteca o aplicación se desarrolla bien en Linux o Windows con la compilación cruzada en cuenta (por ejemplo, no utilizan de plataforma específicas de la API). Usamos boost para cosas como rutas de archivos, hilos, etc. En casos específicos, usamos plantillas/# define para seleccionar la solución específica de la plataforma (por ejemplo, eventos). Cuando esté listo nos moveremos al otro sistema (Linux o Windows), recompilaremos, arreglaremos advertencias/errores y probaremos.
En lugar de perder tiempo averiguando herramientas que pueden compilarse cruzadas en ambas plataformas, utilizamos el sistema que es mejor para cada plataforma y dedicamos tiempo a solucionar problemas específicos y mejorar el software.
Tenemos aplicaciones GUI sólo en Windows atm. entonces no hay GUI para cruzar la compilación. La mayor parte de nuestro desarrollo que se comparte entre Windows y Linux es la red del lado del servidor (sockets, TCP/IP, UDP ...) y luego las herramientas del lado del cliente en las aplicaciones Linux y GUI en Windows.
utilizando con forzosamente para la fuente de gestión de versiones de código que encontramos en muchos casos bastante que el sistema Linux Makefile es mucho más flexible de lo que necesitamos continuación, Windows VS. Especialmente para usar múltiples espacios de trabajo (vistas de versiones de código fuente) donde necesitamos apuntar a directorios comunes, etc. En Linux, esto se puede hacer automáticamente ejecutando una secuencia de comandos para actualizar las variables de entorno, en Visual Studio las variables de entorno de referencia son muy inflexibles porque es difícil actualizar automáticamente entre vistas/ramas.
Re cuestión de sincronización:
Asumo que está pidiendo cómo asegurarse de que los dos sistemas de construcción se sincronizan entre Linux y Windows. En realidad estamos usando Hudson en Linux y CruiseControl en Windows (primero teníamos Windows con control de crucero, cuando fui a la versión de configuración de Linux pensé que Hudson es mejor, así que ahora tenemos un entorno mixto). Nuestros sistemas están funcionando todo el tiempo. Cuando algo se actualiza, se prueba y se libera (ya sea en Windows o en la versión de Linux) para que pueda saber de inmediato si no funciona. Durante las pruebas, nos aseguramos de que todas las funciones más recientes estén disponibles y sean completamente funcionales. Supongo que eso es todo, no hay magia oscura involucrada.
Oh que significa construir scripts ... Cada aplicación tiene su propia solución, en solución a configurar hasta dependencias. En el lado de Linux tengo un archivo MAKE para cada proyecto y un script de compilación en el directorio del proyecto que se ocupa de todas las dependencias, esto en su mayoría significa compilar bibliotecas centrales y un par de marcos específicos necesarios para la aplicación determinada. Como puede ver, esto es diferente para cada plataforma, es fácil agregar secuencias de comandos de línea a construcción que cambien al directorio y hagan el proyecto requerido.
Ayuda a tener proyectos configurados de manera consistente.
En Windows, abra el proyecto y agregue el proyecto de dependencia. Nuevamente no hay magia involucrada.Veo este tipo de tareas como relacionadas con el desarrollo, por ejemplo, se agregaron nuevas funcionalidades a un proyecto y se tuvieron que vincular en los marcos y encabezados. Entonces, desde mi punto de vista, no hay ninguna razón para automatizar estos, ya que son parte de lo que hacen los desarrolladores cuando implementan características.
El sistema de salida está diseñado para un máximo de dos plataformas, por lo que la pregunta es si cmake no está "sobre matar"? Otro punto que me preocupa es que la construcción debe ser reproducible (construir dos veces desde cero dará los productos * SAME * exactamente). Por supuesto, usando el sistema de compilación nativo estoy cerca del objetivo. ¿Es posible que cmake lo rompa y cree vcproj/makefiles diferente dependiendo de la configuración de la persona que lo compila (por ejemplo, para Windows, cada desarrollador hace la compilación en su máquina privada)? – dimba
Solo para una nota sobre Asistencia Visual. Tiene una opción para cargar archivos desde el directorio cuando se usan soluciones vacías. –