configurar - Usando Visual Studio para desarrollar para C++ para Unix
launch json c++ (13)
¿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 compañía tiene aproximadamente 20 desarrolladores que ejecutan Windows XP / Vista y se desarrollan principalmente para Linux y 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 su elección. 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 configuras tu 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 usa la característica del sistema de compilación externa de Visual Studio que finalmente solo ingresa en el servidor de compilación y llama a nuestra utilidad local "make" (que es Boost Build v2 - tiene una gran verificación de dependencia, pero es muy lento para comenzar, 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 evitar 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 parar y esperar por tus herramientas? ¿Los beneficios valen la frustración?
Pensamientos, historias, ayuda?
@monjardin
La razón principal por la que lo usamos es debido a las herramientas de refacturación / búsqueda proporcionadas a través de Visual Assist X (por Whole Tomato). 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
Usar múltiples compiladores suena como un dolor. Podemos darnos el lujo de seguir con gcc en todas nuestras plataformas.
@josh
¡Ay! ¡Eso suena como una gran manera de introducir errores! :-)
Estamos usando una solución similar a la que describiste.
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.
Redes compartidas
Por supuesto, entonces tienes un desfase asesino en la red, pero al menos solo hay una copia de tus archivos.
No quiere 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í.
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 principal problema con esto fue que estábamos revisando un 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.
Wow, 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 referirse al desarrollo de aplicaciones portátiles en Visual Studio y luego migrarlas a Solaris. He hecho esto y tuve experiencias agradables con eso.
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?
VS resopla para alcanzarme.
Hmmm ... tu máquina necesita más memoria y gruñido. Nunca tuve problemas de rendimiento con el mío.
Tengo alrededor de 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 en la banca, bolsas de valores, nichos de corretaje bursátil.
Antes de seguir adelante, debo confesar que todo esto se hizo en VS6 + CVS, y en los últimos tiempos, SVN.
Versiones de código fuente
Los desarrolladores tienen repositorios seguros para fuentes diferentes para que puedan almacenar su trabajo y verificar los paquetes de trabajo en hitos lógicos. Cuando sienten que quieren hacer una prueba de integración, ejecutamos un script que lo verifica en SVN.
Una vez registrado en SVN, se inicia 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 desde SVN a 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, confiamos mucho en los preprocesadores (es decir, #define, etc.) y en los indicadores en el archivo MAKE para dar forma al 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 usualmente: "¿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 podamos 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 que pertenece 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 recordar .
¡También! ... ¡Acabaríamos con un producto que puede ejecutarse tanto en Windows como en Linux!
¡Buena suerte!
He tenido una buena experiencia en el desarrollo de código Playstation2 en Visual Studio usando gcc en cygwin . Si tienes cygwin con gcc y glibc, debería ser casi idéntico a tus entornos objetivo. El hecho de que tenga que ser portátil a través de Solaris y Linux insinúa que cygwin debería funcionar bien.
Sé que esto realmente no responde a su pregunta, pero es posible que desee considerar configurar X sesiones remotas, y ejecutar algo así como KDevelop , que, por cierto, es un IDE muy agradable, o incluso Eclipse , que es más mainstream, y tiene una base de desarrolladores más amplia. Probablemente puedas usar algo como Xming como el servidor X en tus máquinas con Windows.
La mayor parte de mi experiencia de programación está en Windows y soy un gran fanático de Visual Studio (especialmente con Resharper, si estás haciendo 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 usar VS de Windows, aunque mi único objetivo de compilación es Linux ...
Chris, es posible que desee consultar el servidor de compilación de automatización gratuito ''CruiseControl'', que se integra con todos los principales sistemas de control de origen (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 de Linux (Netbeans + SVN, sin automatización de compilación) a 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 desde el 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
Puede hacer que los desarrolladores trabajen en sucursales privadas (más fácil si usa 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.
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 reglas en FinalBuilder que eviten que ingrese / fusione código roto en la línea de base o en ciertas carpetas de sucursal, pero que se lo permitan a otras (no permitimos commits quebrados a / baseline o / branches / *, pero tenemos un / wip / branching folder para desarrolladores que necesitan compartir código potencialmente roto o simplemente quieren comprometerse al final del día).
Puedes distribuir FB en varios "servidores de compilación" para que no termines con 20 personas tratando de construir en una sola casilla, o esperando que una casilla procese todas las confusiones pequeñas.
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.
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 control de fuente, el objetivo final es una máquina Linux (es un servidor de juegos), 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 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 el inicio de la época de Linux en milisegundos", etc. etc., etc.
A riesgo de desviarnos un poco del tema, también creamos pruebas unitarias para esto, y tener las pruebas unitarias para las piezas específicas del SO nos dio la confianza de que funcionaron igual en ambas plataformas.