Me gustaría ejecutar compilaciones diarias o registrar/comprometer compilaciones desencadenadas de proyectos basados en Keil MDK-ARM. Hasta ahora he conseguido que las cosas funcionen con la función de archivo por lotes del IDE. Esto requiere que cree 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 incluye 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, porque el archivo por lotes para la construcción podría cambiarse 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 crear proyectos de 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 en función de las opciones establecidas en el IDE. Debe realizar un seguimiento de estos archivos generados por IDE en el control de código fuente:
Luego, foo.bat se puede iniciar desde un script de compilación.
Si bien esto crea archivos adicionales que deben rastrearse en el control de fuente si desea compilar 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 las diferencias y, por lo tanto, realizar un seguimiento de los cambios en los archivos de texto generados (*.__i) que contienen indicadores del compilador que en el archivo .uvproj. Además, el archivo por lotes llama a las diversas herramientas, armasm, armcc, armlink, directamente. Esto le brinda el resultado directo 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 con secuencias de comandos con las herramientas de Keil. Pedí ver qué podía surgir de los demás. No estoy completamente en desacuerdo con la respuesta de @digikata, pero prefiero tener las banderas del compilador y el mapa de memoria en un formato más fácil para rastrear 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 compilar (no un archivo por lotes generado) desde dentro de un Makefile. Por lo general, funciona mejor bloquear los archivos del proyecto a través del scm, o tomar una copia de compilación de referencia y cambiar el nombre de los proyectos 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 necesita desbloquearlos para cambiar la configuración, guardarlos y volver a registrarlos. 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 se agregan o eliminan archivos del proyecto 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, redirigir 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, analicé el formato de error de Keil a GNU fmt para la integración con el entorno Eclipse CDT. Esto me permite saltar directamente a los 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 pasen al control de versiones para el servidor de compilación.
Espero que esto ayude.
semaj
Digikata
rmaVT
kevin vermeer
davidcary