¿Cómo puedo usar un servidor de compilación con Keil uVision4 (MDK-ARM), escribir una compilación, usar un archivo MAKE?

Me gustaría ejecutar compilaciones diarias o compilaciones activadas por check-in / commit de proyectos basados ​​en Keil MDK-ARM. Hasta ahora he conseguido que funcione la función de archivo por lotes del IDE. Esto requiere que compile el proyecto al menos una vez con el IDE, luego registre el archivo por lotes y los archivos asociados .__iy ._iacreados por el IDE.

Además, el IDE pone muchas cosas específicas del usuario en el archivo por lotes, como la variable PATH de Windows. Esto podría convertirse en un problema con múltiples desarrolladores, ya que el archivo por lotes para compilar podría modificarse en cada confirmación de un desarrollador diferente.

En última instancia, uno solo necesita realizar un seguimiento de los diversos interruptores para armcc , armasm y ArmLink .

¿Hay alguna manera de usar un archivo MAKE más estándar para construir proyectos Keil uVision? ¿Existe algún método para traducir un archivo de proyecto de uVision en un script de compilación más fácil de mantener?

Este es el mejor método que se me ocurrió recientemente:

En las opciones de compilación, seleccione crear archivo por lotes.

Cuando inicia una compilación desde el IDE, se crea un archivo por lotes junto con varios archivos de texto según las opciones establecidas en el IDE. Necesita rastrear estos archivos IDE generados en el control de origen:

• *.murciélago
• * .ini
• *.__yo
• *._I a
• * .lnp
• * .sct

Entonces foo.bat se puede iniciar desde un script de compilación.

Si bien esto crea archivos adicionales que deben rastrearse en el control de origen si desea generar de manera confiable a partir del archivo por lotes generado, elimina la necesidad de confiar en el archivo del proyecto Keil (foo.uvproj) y el IDE. Me resulta más fácil comparar diferencias y, por lo tanto, realizar un seguimiento de los cambios en los archivos de texto generados (* .__ i) que contienen indicadores de compilación que en el archivo .uvproj. Además, el archivo por lotes llama a las diversas herramientas, armasm, armcc, armlink, directamente. Esto le brinda la salida directa de cada uno de esos pasos, así como un potencial aparentemente mejor para migrar un proyecto a una cadena de herramientas diferente en el futuro si es necesario.

Me doy cuenta de que esta respuesta se parece mucho a mi pregunta original, pero realmente no conozco una mejor manera de ejecutar una compilación programada con las herramientas de Keil. Pedí ver qué podría surgir de los demás. No estoy completamente en desacuerdo con la respuesta de @digikata, pero prefiero tener los indicadores del compilador y el mapa de memoria en un formato más fácil para el seguimiento y usar más herramientas de estilo Unix para la compilación en lugar de lanzar una compilación todo en uno con el IDE Creo que la compilación todo en uno del IDE funciona bien en mi estación de trabajo, pero no para el servidor de compilación.

EDITAR : El servidor de compilación se ejecuta en Windows Server 2003. Debo confesar que he cedido a usar la interfaz de línea de comandos IDE en lugar de un archivo por lotes. Esto se volvió demasiado difícil de manejar.

Llamo al Keil IDE a través de la línea de comandos para construir (no un archivo por lotes generado) desde un Makefile. Por lo general, funciona mejor bloquear los archivos del proyecto a través de scm, o tomar una copia de compilación de referencia para cambiar el nombre de los nombres de proyecto relevantes al hacer esto.

El IDE está perfectamente feliz de trabajar con archivos de proyecto de solo lectura, por lo que si los bloquea, lo irritante es que debe desbloquearlos para cambiar la configuración, guardarlos y volver a ingresarlos. Si está en un lugar bastante estable punto en el proyecto esto es bastante menor, incluso deseable.

Si toma una copia de referencia, la compilación tiende a romperse a medida que cambia la configuración del proyecto, especialmente cuando los archivos de proyecto se agregan o se eliminan de la compilación. Capturar explícitamente esos cambios no es necesariamente malo, pero es un paso adicional necesario para mantener las compilaciones.

De cualquier manera, la redirección de la salida a un archivo de registro a través de la opción "-o" le permite acceder al registro de salida completo. El registro no sale una línea a la vez, pero parece que todo está allí. (De hecho, analizo el formato de error Keil a GNU fmt para integrarlo con el entorno eclipse CDT. Esto me permite saltar directamente a errores / advertencias después de la compilación)

La compilación de la línea de comandos también genera los archivos __i, __ia, por lo que tampoco es necesario que entren en el control de versiones para el servidor de compilación.

Espero que esto ayude.