Usando Visual Studio para desarrollar para C++ para Unix

Question

¿Alguien tiene historias de batalla para compartir tratando de usar Visual Studio para desarrollar aplicaciones para Unix? Y no hablo usando .NET con una plataforma virtual Mono o Wine debajo.

Nuestra empresa cuenta con alrededor de 20 desarrolladores todos con Windows XP/Vista y se desarrollan principalmente para Linux & Solaris. Hasta hace poco, todos nos conectábamos a un servidor Linux principal y modificamos/construimos el código a la manera antigua: Emacs, Vi, dtpad: elija lo que desee. Entonces alguien dijo: "oye, estamos viviendo en la Edad Media, deberíamos usar un IDE".

Así que probamos algunos y decidimos que Visual Studio era el único que cumpliría con nuestras necesidades de rendimiento (sí, estoy seguro de que IDE X es un IDE muy agradable, pero elegimos VS).

El problema es cómo configurar su entorno para que los archivos estén disponibles localmente para VS, pero también estén disponibles para un servidor de compilación. Nos decidimos por escribir un plugin de Visual Studio: escribe nuestros archivos localmente y en el servidor de compilación cada vez que presionamos "Guardar" y tenemos un botón de "sincronización" gordo que podemos presionar cuando nuestros archivos cambian en el servidor (para cuando actualizamos los últimos archivos de nuestro servidor de control de origen).

El plugin también utiliza externa característica del sistema de acumulación de Visual Studio que en última instancia sólo de SSH en el servidor de compilación y llama a nuestro local de "hacer" utilidad (que es Boost Build v2 - tiene un gran comprobación de dependencias, pero es realmente lento al principio como resultado, es decir, 30-60 segundos para comenzar). Los resultados se redireccionan a Visual Studio para que el desarrollador pueda hacer clic en el error y llevarlo a la línea de código adecuada (bastante hábil en realidad). El servidor de compilación utiliza GCC y compila de forma cruzada todas nuestras compilaciones de Solaris.

Pero incluso después de haber hecho todo esto, no puedo dejar de suspirar cada vez que empiezo a escribir código en Visual Studio. Hago clic en un archivo, comienzo a escribir y VS reprende para ponerme al día.

¿Hay algo más molesto que tener que detenerse y esperar por sus herramientas? ¿Los beneficios valen la frustración?

Pensamientos, historias, ayuda?

Answer 1

Guau, eso suena como un uso realmente extraño para Visual Studio. Estoy muy feliz trajinando en vim. Sin embargo, lo único que me encanta de Visual Studio es el depurador. Parece que ni siquiera lo estás usando.

Cuando abrí la pregunta, pensé que debía estar refiriéndose al desarrollo de aplicaciones portátiles en Visual Studio y luego a migrarlas a Solaris. He hecho esto y tuve experiencias agradables con eso.

Answer 2

Siento tu dolor. Tenemos una aplicación que es 'multiplataforma'. Una aplicación cliente/servidor típica donde el cliente necesita poder ejecutarse en Windows y Linux. Debido a que nuestra base de clientes utiliza principalmente Windows, trabajamos con VS2008 (el depurador hace que la vida sea mucho más fácil), sin embargo, aún necesitamos realizar compilaciones de Linux.

El problema principal con esto fue que estábamos revisando el código que no sabíamos que se compilaría bajo gcc, lo que probablemente rompería las cosas de CI que habíamos configurado. Así que instalamos MingGW en todas las máquinas de nuestros desarrolladores, lo que nos permite probar que la copia de trabajo se compilará bajo gcc antes de volver a enviarla al repositorio.

Answer 3

Estamos utilizando una solución similar a la que describió.

Tenemos nuestro código almacenado en el lado de Windows del mundo y UNIX (QNX 4.25 para ser exactos) tiene acceso a través de un montaje NFS (gracias a los servicios de UNIX para Windows). Tenemos una ssh en UNIX para ejecutar make y la tubería para enviar a VS. El acceso al código es rápido, las compilaciones son un poco más lentas que antes, pero nuestra compilación más larga es actualmente de menos de dos minutos, no es un gran problema.

Usar el desarrollo de VS para UNIX ha valido la pena para configurarlo, porque ahora tenemos IntelliSense. Menos tipeo = desarrollador feliz.

Answer 4

Redes compartidas.

Por supuesto, entonces usted tiene un atraso mortal en la red, pero al menos solo hay una copia de sus archivos.

No desea escuchar lo que hice cuando estaba desarrollando en ambas plataformas. Pero vas a: copiar arrastrando y soltando varias veces al día. Construir y ejecutar localmente, y revisarlo periódicamente en Unix para asegurarse de que gcc estuviera contento y de que las pruebas de la unidad también estuvieran contenidas en esa plataforma. No es realmente un ciclo de cambio rápido allí.

Answer 5

@monjardin

La razón principal por la que usamos es a causa de las herramientas de re-factoring/búsqueda proporcionados a través de Visual Assist X (por Whole tomate). Aunque hay varios otros agradables como Intelli-sense. También estamos investigando integraciones con nuestras otras herramientas AccuRev, Bugzilla y Totalview para completar el entorno.

@roo

El uso de múltiples compiladores suena como un dolor. Podemos darnos el lujo de seguir con gcc en todas nuestras plataformas.

@josh

¡Yikes! ¡Eso suena como una gran manera de introducir errores! :-)

Answer 6

VS resuena para alcanzarme.
Hmmm ... su máquina necesita más memoria & gruñido. Nunca tuve problemas de rendimiento con el mío.

Tengo aproximadamente una década de experiencia haciendo exactamente lo que usted propone, la mayor parte en la industria financiera, desarrollando sistemas en tiempo real para clientes de la banca, bolsas de valores, nichos de corretaje bursátil.

Antes de seguir adelante, tengo que confesar que todo esto se hizo en VS6 + CVS, y en los últimos tiempos, SVN.

código fuente de versiones

Los desarrolladores tienen repositorios SourceSafe separadas para que puedan almacenar su trabajo y comprobar que los paquetes de trabajo en etapas lógicas. Cuando sienten que quieren hacer una prueba de integración, ejecutamos un script que lo verifica en SVN.

Una vez registrado en SVN, iniciamos un proceso que generará automáticamente makefiles relevantes para compilarlos en las máquinas de destino para la integración continua.

Tenemos otro conjunto de scripts que sincroniza cosas nuevas de SVN con las carpetas que VS cuida. Hay un poco de espacio porque VS no puede recoger automáticamente nuevos archivos; generalmente lo manejamos de forma manual. Esto solo ocurre regularmente los primeros días del proyecto.

Esa es una descripción general de cómo mantenemos los códigos.Tengo que decir que probablemente he pasado por alto algunos detalles (avíseme si está interesado).

Codificación

Desde el aspecto de codificación, que dependen en gran medida de los pre-procesadores (es decir, #define, etc) y banderas en el makefile para dar forma a proceso de compilación. Para la portabilidad multiplataforma, utilizamos GCC. Algunas veces, nos vimos obligados a utilizar un CC en HP-UX y algunos otros compiladores, pero no tuvimos mucha pena. Lo único que es un dolor constante, es que tuvimos que tener cuidado con los espacios de montón de subprocesos en todas las plataformas. El compilador no nos ahorra eso.

¿Por qué?

La pregunta es, por lo general, "¿Por qué la h * ll incluso podría tener un modo de desarrollo tan complicado?". Nuestra respuesta suele ser otra pregunta que diga: "¿Tienes alguna idea de lo loco que es depurar una aplicación de subprocesos múltiples examinando el volcado del núcleo o utilizando gdb?". Básicamente, el hecho de que podemos rastrear/recorrer cada línea de código cuando estás depurando un error oscuro, ¡hace que valga la pena el esfuerzo!

¡Más! ... La función Intellisense de VS hace que sea tan fácil encontrar el método/atributo perteneciente a las clases. También escuché que el VS2008 tiene capacidades de refactorización. Cambié mi enfoque a Java en Eclipse que tiene ambas características. Sería más productivo centrarse en la lógica de negocios de codificación en lugar de dedicar energía haciendo que su mente haga cosas como ¡recuerde!

También! ... ¡Acabaríamos con un producto que puede ejecutarse tanto en Windows como en Linux!

¡Buena suerte!

Answer 7

Desarrollamos para Mac y PC. Simplemente trabajamos localmente en cualquier idea que prefiramos, principalmente VS pero también xcode. Cuando sentimos que nuestros cambios son lo suficientemente estables para los servidores de compilación, los controlamos. Los dos servidores de compilación (Mac y PC) buscan comprobaciones de control de origen, y cada uno hace una compilación. Los errores de compilación se envían por correo electrónico al equipo.

La edición de archivos en vivo en el servidor de compilación me parece precaria. ¿Qué sucede si solicita una compilación mientras que otro desarrollador tiene modificaciones que no se compilarán?

Answer 8

Sé que esto realmente no responde a su pregunta, pero es posible que desee considerar la configuración de sesiones X remotas, y ejecutar algo como KDevelop, que, por cierto, es un IDE muy bueno - o incluso Eclipse , que es más convencional, y tiene una base de desarrolladores más amplia. Probablemente pueda usar algo como Xming como el servidor X en sus máquinas con Windows.

Answer 9

He tenido una buena experiencia en el desarrollo del código de Playstation2 en Visual Studio usando gcc en cygwin. Si tiene cygwin con gcc y glibc, debe ser casi idéntico a su entorno de destino. El hecho de que tenga que ser portátil a través de Solaris y Linux insinúa que cygwin debería funcionar bien.

Answer 10

La mayor parte de mi experiencia de programación está en Windows y soy un gran admirador de Visual Studio (especialmente con Resharper, si usted está haciendo la codificación C#). Estos días he estado escribiendo una aplicación para Linux en C++. Después de probar todos los IDE (Netbeans, KDevelop, Eclipse CDT, etc.), descubrí que Netbeans era el menos malo. Para mí, los requisitos mínimos absolutos son que puedo acceder al código en un solo paso y que tengo intellisense, idealmente con algunas funciones de refactorización. Me sorprende cómo los IDEs de Linux de hoy en día ni siquiera se parecen a lo que Visual Studio 6 tenía hace más de diez años.El mayor punto de dolor en este momento es cuán lento y mal implementado es el intellisense en Netbeans. Toma 2-3 segundos para poblar en una máquina rápida con 8GB de RAM. El intellisense de Eclipse CDT fue aún más lento. Lo siento, pero esperar 2 segundos para intellisense no es suficiente.

Así que ahora estoy buscando en el uso de VS desde Windows, a pesar de que mi único objetivo es la acumulación de Linux ...

Chris, es posible que desee ver en la automatización libre servidor de compilación 'climatizador', que integra con todos los principales sistemas de control de fuente (svn, tfs, sourcesafe, etc.). Su propósito es reaccionar a los controles en un sistema de control de fuente. En general, usted lo configura de modo que cada vez que alguien ingrese el código, se inicie una compilación y (idealmente) se ejecuten las pruebas unitarias. Para algunos idiomas, existen algunos complementos geniales que hacen análisis de código, miden la cobertura del código de prueba de la unidad, etc. Las notificaciones se envían al equipo sobre versiones exitosas/rotas. Aquí hay una publicación que describe cómo se puede configurar para C++: link (thoughtworks.org).

Estoy empezando con la conversión de una configuración simple solo en Linux (Netbeans + SVN, sin automatización de compilación) a usar Windows VS 2008 con back-end de automatización de compilación que ejecuta pruebas unitarias además de hacer compilaciones en linux Me estremezco por la cantidad de tiempo que me tomará configurar todo, pero cuanto antes mejor, supongo.

En mi estado final ideal, podré autogenerar el archivo del proyecto Netbeans del proyecto VS, de modo que cuando necesite depurar algo en Linux lo pueda hacer desde ese IDE. Los archivos del proyecto VS están basados ​​en XML, por lo que no debería ser demasiado difícil.

Si alguien tiene alguna sugerencia para esto, realmente lo agradecería.

Gracias,

Christophe

Answer 11

usted podría tener los desarrolladores trabajan en las ramas privadas (más fácil si usted está usando un DVCS). Luego, cuando desee registrar algún código, verifíquelo en su sucursal privada en [windows | unix], actualice su sandbox en [unix | windows] y compile/pruebe antes de volver a la sucursal principal.

Answer 12

Consulte "Final Builder" (http://www.finalbuilder.com/). Seleccione un sistema de control de versiones (por ejemplo, cvs o svn, para ser honesto, los cvs se adaptan mejor a este caso de uso particular por los sonidos) y luego configure desencadenadores de compilación en FinalBuilder para que los checkins generen una compilación y le envíen los resultados .

Puede configurar conjuntos de reglas en FinalBuilder que eviten que ingrese/fusione código roto en la línea de base o en ciertas carpetas de bifurcaciones pero que se lo permitan otros (no permitimos commits /baseline o/branches/* rotos, pero tenemos una carpeta/wip/branching para desarrolladores que necesitan compartir código potencialmente roto o simplemente quieren comprometerse al final del día).

Puede distribuir FB en varios "servidores de compilación" para que no terminen con 20 personas que intentan crear en una sola casilla, o esperando que una casilla procese todas las confusiones poco definidas.

Nuestro proyecto tiene un servidor basado en Linux con clientes Mac y Win, todos comparten una base de código común. Esta puesta en marcha funciona ridículamente bien para nosotros.

Answer 13

Estoy haciendo exactamente lo mismo en el trabajo. La configuración que uso es VS para el desarrollo de Windows, con una VM Linux que se ejecuta en VirtualBox para la compilación local/verificación de ejecución. VirtualBox tiene una función en la que puede crear una carpeta en el sistema operativo anfitrión (Windows 7 en mi caso) disponible como un sistema de archivos montable en el huésped (Ubuntu LTS 12.04 en mi caso).De esta forma, después de iniciar una compilación de VS, y se guardan los archivos, puedo iniciar inmediatamente una marca en Linux para verificar que se cree y ejecute OK allí.

Usamos SVN para el control de código fuente, el objetivo final es una máquina Linux (es un servidor de juego), por lo que usa el mismo archivo make que mi compilación de Linux local. De esta forma, si agrego un archivo al proyecto/cambio una opción del compilador, generalmente añadiendo/cambiando una -D, hago las modificaciones inicialmente bajo VS, y luego cambio inmediatamente el archivo make de Linus para reflejar los mismos cambios. Luego, cuando me comprometo, el sistema de compilación (Bamboo) recoge el cambio y realiza su propia compilación de verificación.

La experiencia ganada dice que este es un orden de magnitud más fácil si construyes así desde el primer día.

El primer proyecto en el que trabajé comenzó solo como Windows, me contrataron para llevarlo a Linux, ya que querían cambiar a un entorno de servidor homogéneo, y todo lo demás era Linux. Adaptar un proyecto de Windows a este tipo de configuración fue un gran gasto de esfuerzo.

El proyecto número dos se realizó "dos versiones del sistema" desde el primer día. Queríamos mantener la capacidad de usar VS para desarrollo/depuración ya que es un IDE muy pulido, pero también teníamos el requisito de implementación final en servidores Linux. Como mencioné anteriormente, cuando el proyecto fue construido teniendo esto en mente desde el principio, fue bastante sencillo. La peor parte fue un solo archivo: system_os.cpp que contenía rutinas específicas del sistema operativo, cosas como "obtener la hora actual desde Linux epoch start en milisegundos", etc. etc.

A riesgo de salir un poco del tema , también creamos pruebas unitarias para esto, y tener las pruebas unitarias para las piezas específicas del sistema operativo proporcionó una gran cantidad de confianza de que funcionaron igual en ambas plataformas.