Almacenamiento de framework / middleware de terceros en control de fuente que necesita alterar su comstackdor / IDE

Sé que hay publicaciones que preguntan cómo se almacenan las bibliotecas de terceros en el control de código fuente (como este y este ). Si bien esas son excelentes respuestas, todavía no puedo encontrar la respuesta a esto:

¿Cómo se almacenan los binarys de middleware / frameworks de terceros que necesitan modificar su comstackdor / IDE para que la biblioteca funcione correctamente? Nota: para mis necesidades, no necesito almacenar el origen del middleware, solo almaceno los files de cabecera / lib / JAR … así que está listo para ser enlazado.

Normalmente, simplemente vincula bibliotecas a su aplicación, y está bien. Pero, ¿qué hay de los middleware / frameworks que necesitan más?

Ejemplos específicos:

  • Preprocesador de Qt moc.

  • Recostackdor ZeroC Ice Slice (hielo) (similar al preprocesador CORBA IDL).

Básicamente, estos frameworks / middleware necesitan generar su propio código antes de que su aplicación pueda vincularlo.

Desde el punto de vista del desarrollador, lo ideal es que simplemente se registre y todo esté listo para funcionar. Pero entonces mi IDE / comstackdor no se configurará correctamente aún, por lo que la compilation fallará …

¿Qué piensas?

Haga una copy de security de todo, incluida la configuration del IDE, el sistema operativo, etc. Esto es lo que hago

1) Almacene todas las bibliotecas de terceros en control de fuente. Tengo una sucursal para todas las bibliotecas.

2) Copia de security de toda la cadena de herramientas que se utilizó para build. Esto incluye todas las herramientas. Cada herramienta se instala en el mismo directory en cada computadora de desarrollo, por lo que es sencillo configurar una máquina de desarrollo de forma remota.

3) Esta es la configuration IDE de desarrollador más hardcore, pero prepare 1 perfecta, que está limpia, y luego cree una image VMWare / VirtualPC. Esto será útil cuando parezca que los instaladores no pueden trabajar en el futuro.

Aprendí esta lección de la manera dolorosa porque a menudo tengo que pasar por el código de Visual Studio 6 que no se construye correctamente.

Creo que una mejor solución es asegurarse de que la compilation sea autónoma y descargue todo el software necesario por sí mismo, a less que usted indique lo contrario. Esta es la forma en que funciona maven, y es realmente útil. El inconveniente es que a veces es necesario download un server de aplicaciones o similar, que es muy poco práctico, pero al less la construcción tiene éxito y se convierte en la responsabilidad de los nuevos desarrolladores de mejorar la construcción si es necesario.

Por supuesto, esto no funciona muy bien si su software necesita instalaciones asistidas, pero trataría de evitar tales dependencies en cualquier caso. Puede agregar routes alternativas (por ejemplo, el script ant comstack el código si eclipse aún no lo ha hecho). Si esto no es factible, una opción alternativa es fallar con una indicación clara de lo que salió mal (por ejemplo, 'CORBA_COMPILER_HOME' no está configurado, por favor, configure y vuelva a intentarlo ').

Dicho todo esto, la solución más completa es, por supuesto, enviar todo con tu aplicación (es decir, SO, IDE, las obras), pero dudo que eso sea aplicable en el caso general, ¿cómo te sentirías acerca de ese tipo de requisitos para build? un producto de software? También limita a las personas que desean adaptar su software a nuevas plataforms.

¿Qué tal si agregas 1 paso?

Una secuencia de commands nant que se inicia con un file bat. El desarrollador solo tendría que ejecutar un file .bat, el file bat podría iniciar nant y se podría hacer que la secuencia de commands de Nant haga lo que necesite.

Esta es en realidad una pregunta bastante sutil. Está hablando de cómo administrar las características del entorno que son necesarias para permitir que su construcción avance. En este caso, es el nivel superior de su cadena de herramientas de código, pero el problema puede generalizarse para include toda la cadena de herramientas e incluso aspectos key del sistema operativo.

En mi lugar de trabajo, tenemos varios requisitos del sistema operativo subyacente antes de que nuestro código se ejecute correctamente. Esto incluye configuraciones específicas de la máquina, así como garantizar que estén presentes las versiones correctas de las bibliotecas del sistema y los times de ejecución del idioma. Hemos solucionado esto manteniendo una image de máquina de compilation genérica estándar que contiene los requisitos de herramientas que necesitamos. Podemos llevar esto a una máquina virgen y get un entorno básico que contenga la cadena de herramientas completa y todos los progtwigs auxiliares.

Luego usamos fsvs para controlar la versión de cualquier configuration adicional, que se puede acoplar en grupos específicos de máquinas según sea necesario.

Finalmente, utilizamos scripts personalizados enganchados en nuestro server de CI (utilizamos Hudson ) para realizar cualquier paso de preprocess requerido para proyectos específicos.

Las principales ventajas para nosotros de este enfoque es:

  1. Podemos build e implementar máquinas de desarrollo y producción con mucha facilidad (y hacer que TI maneje este lado del problema).
  2. Podemos replace fácilmente las máquinas fallidas.
  3. Tenemos un entorno conocido para las testings (instalamos todo en un "server de producción" simulado antes de lanzarlo).
  4. Nosotros (el equipo de software) controlamos los detalles de configuration crítica y cualquier paso explícito de preprocesamiento.

Tercerizaría la tarea de build el middleware en un server de compilation especializado y solo includeía el resultado binary como dependencies de terceros normales bajo el control de código fuente.

Si esta estrategia se puede aplicar con éxito depende de si todos los desarrolladores deben ser capaces de cambiar el código de midware y volver a comstackrlo con frecuencia. Pero este problema también podría resolverse a través de un Servidor de Integración Continua como Teamcity que permite crear comstackciones privadas.

Su process de compilation se vería así:

  • Repo Middleware que contiene código middleware
  • Servidor de compilation, comstackndo middleware
  • Empujar la salida de compilation de middleware al repository del proyecto como references de terceros

Actualización: Esto realmente no responde cómo modificar el IDE. Es solo una especie de cosa de reemploop de Maven para C ++ / Python / Java. No debería necesitar modificar el IDE para comstackr material, de ser así, necesita un IDE diferente o un sistema que genere / modifique files IDE por usted. (Consulte CMake para get un generador de files de proyecto c / c ++ multiplataforma.)


Escribí un sistema (primero en Ant / Beanshell en dos lugares diferentes, luego lo reescribí en Python en mi trabajo actual) donde los terceros se comstackn por separado (por alguien), se almacenan y se comparten a través de HTTP.

Una descripción algo apresurada sigue :

Al inicio, el sistema de compilation examina todos los modules en repos, ejecuta el objective de configuration de cada module, que descarga la versión específica de una aplicación o lib de terceros que utiliza la revisión de código actual. Luego se descomprimen, se agregan PATH / INCLUDE, etc. (o, para libs pequeñas, se copyn a un solo directory para el repository actual) y luego se ejecuta Visual Studio con / useenv.

El file de cada module verifica todo lo que necesita, y si necesita installation y licencia, como Visual Studio, Matlab o Maya, debe estar en la computadora local. Si eso no está allí, el file cmd fallará con un bonito post de error. De esta forma, también puedes verificar que la versión correcta esté allí

Entonces, hay una cantidad de directorys en el disco local involucrado. % work% debe establecerse usando una variable de entorno global, preferible en un disco diferente que el sistema o el checkout de origen, al less si se realiza un pesado C ++.

  • % work% <- local store para todos los files temporales, descomprimir y para cada file temporal de la copy de trabajo
  • % work% / _ cache <- zip descargado (2 gb)
  • % work% / _ local <- cremalleras locales (para desarrollo o recuperado de otras maneras mientras se viaja)
  • % work% / _ unzip <- descomprime files en _cache (10 gb)
  • % work% & _ content <- textures / models 3D y otros files grandes (sincronizados manualmente, esto es 5 gb hoy, no es adecuado para VC tampoco)
  • % work% / D_trunk / <- store para copy de trabajo desprotegida en d: / trunk
  • % work% / E_branches / v2 <- store para copy de trabajo check out en e: / branches / v2

Entonces, si trunk usa Boost 1.37 y branches / v2 usa 1.39, ambos boost-1.39 y boost-1.37 residen en / _cache / (como cremalleras) y / _unzip / (como files raw).

Al iniciar Visual Studio utilizando files bat de d: / trunk / BuildSystem / Visual Studio.cmd, INCLUDE apunta a /_unzip/boost-1.37, mientras que si ejecuta e: / branches / v2 / BuildSystem / Visual Studio.cmd, INCLUDE apunta a /_unzip/boost-1.39.

En el repository, solo es necesario almacenar un pequeño set de files binarys de arranque (es decir, wget y 7z).

Actualmente, descargamos aproximadamente 2 gb de datos empaquetados, que se descomprimen a 10 gb (¡los files pdb son enormes!), Por lo que mantener este fuera del control de la fuente es esencial. Tener este sistema nos permite mantener el tamaño del repository lo suficientemente pequeño como para usar DVCS como Mercurial (o Git) en lugar de SVN, lo cual es muy bueno. (Estoy pensando en utilizar la extensión de files grandes de Mercurials o compartir files en lugar de un directory http servido por separado).

Funciona a la perfección. Los desarrolladores solo necesitan verificar, establecer una variable ambiental para su caching local y luego ejecutar Visual Studio a través de un file por lotes específico en el repository. Sin descomprimir ni comstackr ni nada. Un nuevo desarrollador puede configurar su computadora en poco time. (La installation de Visual Studio toma el order de una magnitud más de time).

La primera vez en una computadora nueva toma algo de time, pero luego es rápida, solo unos pocos segundos. Las descargas / descomprimidos se comparten en la computadora local, verifique sucursales / versiones adicionales no ocupe más espacio. Trabajar fuera de línea también es posible, solo necesita get los files zip manualmente si se han cargado nuevos. (Este mecanismo es esencial para probar nuevas versiones / comstackciones de bibliotecas de terceros).

Los conceptos básicos están en un repository de bitbucket, pero necesita más trabajo antes de que esté listo para el público. Además de doc y polaco, planeo:

  • extiéndalo para usar cmake en lugar de files vcproj sin procesar, para hacerlo más multiplataforma.
  • secuencia de commands de todo el process, desde la descarga / descarga de packages de terceros hasta la compilation y compression (incluso el almacenamiento de la descarga en un repository local) … actualmente eso está en mi computadora dev. No está bien. Arreglará. 🙂

En cuanto a moc, usamos el complemento Visual Studio de Qt , que almacena esto en los files .vcproj. Funciona bien. Creo que CMake es una de las mejores respuestas para esto