Desarrollo simultáneo de C++ en Linux y Windows

Question

Tenemos un puñado de desarrolladores que trabajan en un proyecto C++ no comercial (léase: simplemente por diversión) multiplataforma. Ya hemos identificado todas las bibliotecas multiplataforma que necesitaremos. Sin embargo, algunos de nuestros desarrolladores prefieren usar Microsoft Visual C++ 2008, otros prefieren codificar en Emacs en GNU/Linux. Nos preguntamos si es posible para todos nosotros trabajar más o menos simultáneamente en ambos entornos, desde el mismo repositorio de código. En última instancia, queremos que el proyecto se compile limpiamente en ambas plataformas desde el principio.

Cualquiera de nuestros desarrolladores está felizmente dispuesto a cambiar al otro entorno si esto no es posible. Todos usamos tanto Linux como Windows regularmente y disfrutamos de ambos, así que no se trata de tratar de educar a un desarrollador sobre las virtudes de la otra plataforma. Se trata de que cada uno de nosotros pueda desarrollarse en el entorno que más disfrutamos y aun así colaborar en un proyecto divertido.

¿Alguna sugerencia o experiencia para compartir?

Answer 1

Usa CMake para administrar tus archivos de compilación.

Esto le permitirá configurar un único repositorio, con un conjunto de archivos de texto. Cada desarrollador puede ejecutar los scripts cmake apropiados para construir el entorno de compilación correcto para su sistema (Visual Studio 2008/2005/GNU C++ compila scripts/etc).

Hay muchas ventajas aquí:

• Cada desarrollador puede utilizar su propio entorno de construcción
• Las dependencias pueden ser manejados de forma muy limpia, incluyendo deps específicos de la plataforma.
• Las versiones pueden estar fuera de la fuente, lo que ayuda a evitar el ingreso accidental de archivos inapropiados
• Migración fácil a un nuevo desarrollador. entornos (es decir: cuando se lanza VS 2010, algunos desarrolladores pueden migrar allí simplemente reconstruyendo su carpeta de compilación)

Answer 2

El problema no es realmente editar los archivos fuente de C++, sino el proceso de compilación en sí. VS no usa la misma arquitectura de Makefile como normalmente lo hace el desarrollo de Linux. Una sugerencia radical, pero ambos grupos podrían usar el mismo IDE de C++ y el mismo proceso de compilación. Consulte Code::Blocks para obtener más información.

Answer 3

Esto es posible (lo hago para ganar mi dinero diario :-)).

Pero debe tener en cuenta las diferencias en las bibliotecas suministradas por el sistema operativo que pueden ser muy molestas. Dos buenas opciones para moverse que son BOOST y QT.

Ambos le proporcionan funciones independientes de la plataforma de elementos útiles que no maneja la lib y la STL.

Answer 4

Personalmente uso cmake/mingw32/Qt4 para todas mis necesidades de C++. QtCreator es un IDE de plataforma cruzada que está algo optimizado para la programación de qt4.

Answer 5

Lo he hecho y lo he visto sin demasiados problemas.

Deberá intentar aislar el código que es diferente para las diferentes plataformas. Además, querrá pensar en su estructura de directorio .Algo así como

• proyecto/src < - .cc y .h
• proyecto/src/linux | ganar < - código que es específico de una plataforma o el otro proyecto
• /Linux < - hacer archivos y otras cosas relacionadas con el proyecto
• proyecto/WIN < - .sln y .csproj archivos

Básicamente lo que desea es ser muy claro qué es específi c a cada sistema y lo que es común.

Además, unidad de prueba van a ser realmente importante ya que puede haber diferencia menor y que desea hacer más fácil para los chicos de Windows para ejecutar algunas pruebas para asegurarse de que funciona el código de Linux como se esperaba y el otro camino alrededor.

Answer 6

que he hecho esto de dos maneras:

1. Cada plataforma tiene su propio sistema de construcción. Cada vez que alguien cambia algo (agregando un archivo fuente), o bien adaptan la otra plataforma, o envían una notificación por correo y alguien más familiarizado con la otra plataforma la adapta en consecuencia.
2. Use CMake.

No puedo decir que realmente me haya gustado CMake, pero una herramienta multiplataforma ciertamente tiene sus ventajas.

En general, utilizar compiladores diferentes para compilar el código desde las primeras líneas siempre es una buena idea, ya que ayuda a mejorar la calidad del código.

Answer 7

Tenía tanta experiencia trabajando en Acronis. Teníamos la misma base de código utilizada para construir binarios (instaladores totalmente empaquetados, en realidad) dirigidos a Win32/64, Linux y OS X (y un montón de otras plataformas más exóticas, como EFI), con todos los que trabajan en su IDE de elección. El truco aquí es evitar las soluciones específicas del compilador y de IDE, y hacer que su proyecto sea completamente edificable desde archivos de creación de plataformas transparentes. Tenga en cuenta que puede usar perfectamente cualquier sistema make junto con VC++, por lo que no es un problema (utilizamos Watcom make por razones históricas, pero no lo recomendaría).

Otro truco que puede hacer es agregar un script make que produce automáticamente archivos de proyecto de las listas de entrada en sus archivos make, para todos los IDEs que use (por ejemplo, VS y Eclipse CDT). De esta forma, cada desarrollador genera esas cosas para sí mismo, y luego abre esos proyectos en IDE para editar/construir/depurar, pero el repositorio de origen solo tiene archivos make.

Asegurar que el código sea compilable para todos puede ser un problema, principalmente porque VC++ es generalmente menos laxo en la aplicación de las reglas que g ++ (por ejemplo, le permitirá vincular un valor r a una referencia no const, aunque con advertencia). Si compila con las advertencias de tratamiento como errores y los niveles de advertencia más altos (con tal vez algunas advertencias seleccionadas manualmente), evitará esto principalmente. Tener una configuración contigua de construcción rodante es otra forma de atraparlos temprano. Otro enfoque que hemos utilizado en Acronis es tener el entorno de compilación de Windows con herramientas de compilación cruzada basadas en Cygwin, por lo que cualquier desarrollador de Windows podría hacer una compilación dirigida a Linux (con la misma versión de G ++ y todo) de su cuadro, y ver si eso falla, para verificar que sus cambios se compilarán en g ++.

Answer 8

como se menciona en publicaciones anteriores, Qt es un método muy fácil para realizar un desarrollo multiplataforma simultáneo real, independientemente de su IDE y con muchos compiladores diferentes (incluso para Symbian, ARM, Windows CE/Mobile ...).

En mi última y actual empresa trabajo en equipos mixtos de desarrolladores de Linux y Windows, que trabajan en conjunto utilizando Subversion y Qt (que tiene un sistema de construcción muy fácil y poderoso "QMake", que oculta todas las plataformas diferentes/compiladores entornos de compilación específicos - solo tiene que escribir un archivo de compilación para todas las plataformas - ¡así de fácil!).

Y: Qt contiene casi todo lo que necesita:

• sencillo manejo de cadenas, con el soporte de traducción fácil y rápida conversión de cadenas (UTF-8, utf16, ascos ...)
• clases simples para File I/O, imágenes, redes, etc
• cómodas clases de GUI
• diseñador gráfico para el diseño/diseño de interfaz gráfica de usuario
• herramienta gráfica para crear traducciones traducción dinámicos para sus aplicaciones (se puede ejecutar uno binario con diferentes idiomas seleccionables - incluso Cirílica, asiáticos ...)
• marco de pruebas integrada (pruebas unitarias)

Así Qt es un ambiente equipado y muy fiable completa - lo uso durante 10 años.

Y: Qt se integra perfectamente en IDEs como VC++, Eclipse o proporciona su propio IDE "QtCreator".

ver: http://www.trolltech.com + http://doc.trolltech.com

Best Regards, Chris

Answer 9

Otro voto para cmake.
Una cosa a tener en cuenta es que los nombres de los archivos están codificados pero no son sensibles a mayúsculas y minúsculas en Windows. Son sensibles a las mayúsculas y minúsculas en la mayoría de los sistemas de archivos de Unix.

Esto es generalmente un problema con #include

por ejemplo. dieron una FooBar.h archivo

#include "foobar.h" // works on Windows, fails on Linux. 

Answer 10

Estoy de acuerdo con todos los presentes que se ha sugerido cmake para el desarrollo multiplataforma en C++. Es una excelente herramienta.

Otra cosa que sugeriría es usar eclipse CDT como entorno de desarrollo. Funciona en cualquier lugar donde pueda ejecutar Java y gcc y eso unifica su entorno de desarrollo.

Creo que fue Alan Jackson quien dio énfasis a la prueba unitaria. Para hacerlo, necesitarías algunas bibliotecas de prueba de unidades de plataforma cruzada. Leí esto hace post respecto a los marcos de prueba de unidades C++. Está un poco desactualizado pero considerado. El que falta que también funciona en ambas plataformas es googletest.

Finalmente, si desea ejecutar esas pruebas automáticamente en ambas plataformas, cmake tiene otra herramienta llamada ctest que es muy buena para hacerlo.

Answer 11

También estamos trabajando en un proyecto multiplataforma. Estamos usando Emacs para codificar, SCons para compilar y Visual Studio 2008 para depurar. Es la primera vez que uso Emacs + SCons y debo decir que es muy ingenioso una vez que descubres cómo funcionan SConstruct y SConscripts.

Answer 12

Llegué tarde a esta pregunta, y hay muchas buenas respuestas aquí, pero no he visto a nadie enumerar todos los problemas que me he encontrado (la mayor parte de mi trabajo en C++ es y ha sido cruzado -plataforma), entonces:

• Compilación multiplataforma. Todos han cubierto esto bastante bien. CMake y SCons son útiles entre otros.
• Diferencias de plataforma. Estos no están limitados a Linux v Windows. Las diferentes versiones de Windows tienen muchos problemas sutiles. Si alguna vez quiere saltar de Linux a OS X, encontrará lo mismo. También lo hacen las diferencias de la arquitectura del procesador: 32 v 64 bits no suele importar, hasta que lo hace y las cosas se rompen muy mal. Esto es algo a lo que los programadores de C++ se enfrentan más que en la mayoría de los otros lenguajes, cuyas implementaciones están trabajando duro para ocultar este tipo de cosas a los programadores.
• Pruebe todo. Alan mentions unit tests pero permítanme enfatizarlos. El problema real con la programación multiplataforma no es un código que no compilará: es un código que compila muy bien y hace lo incorrecto en casos sutiles. Las pruebas unitarias importan aquí mucho más de lo que lo hacen cuando se trabaja en una plataforma única.
• Use bibliotecas portátiles siempre que sea posible. Hacer esto bien está lleno de errores sutiles. Es mejor aprovechar el trabajo de otra persona que tirar el tuyo. Qt es útil aquí, al igual que NSPR y APR (los dos últimos son C, pero existen envoltorios si no quiere jugar con ellos directamente). Estas son las bibliotecas que apuntan explícitamente a la abstracción de plataforma como objetivo, pero la mayoría de las otras bibliotecas tu uso debe ser revisado para esto. Sea razonablemente cauteloso con las geniales bibliotecas que no tienen un historial de portabilidad. No digo que no los uses: simplemente prueba primero. Hacer esto bien le ahorra un enorme esfuerzo en las pruebas.
• Pavel mentions continual integration. Esto puede no importar si solo hay un puñado de ustedes. Pero descubrí que la cantidad de plataformas que obtiene cuando considera todas las diferencias entre el sistema operativo, la variante del sistema operativo y el procesador significa que, sin algún tipo de ciclo de prueba de desarrollo continuo, siempre le faltará algún caso límite. Si su proyecto se vuelve más grande que un puñado de personas considere hacer esto.
• Control de versiones. El problema más obvio es el manejo de nuevas líneas y la sensibilidad de las mayúsculas y minúsculas, pero hay otras. La mayoría de los VCS de código abierto conocidos lo hacen ahora mismo, pero es notable que generalmente tardan varios años en encontrar todos los errores relacionados con la portabilidad. Como ejemplo, Mercurial, que ha tenido portabilidad como uno de sus puntos de venta, tiene una serie de soluciones que abarcan tres o cuatro lanzamientos que tratan con nombres de archivos de Windows en situaciones poco comunes. Asegúrate de que puedes verificar lo que los demás registran desde el principio.
• Scripts. Use Perl/Python/Ruby (o algo así) para sus scripts. Tratar de mantener el shell de Linux y los scripts por lotes de Windows sincronizados es dolorosamente tedioso.

A pesar de todo lo anterior: la plataforma cruzada en general es bastante factible, y no hay una razón real para evitarla. Mi experiencia es que los problemas tienden a surgir esporádicamente, pero cuando lo hacen toman más que suficiente tiempo. Si ha estado programando durante un tiempo, no lo encontrará inusual.

Answer 13

Echa un vistazo a premake ... Es bastante similar a CMake pero escrito usando lua.

Lo he usado en una serie de proyectos de desarrollo y me resulta fácil aprender e integrarme en las estructuras de proyectos y empresas existentes.

Pruébalo!

http://industriousone.com/premake