Comment puis-je utiliser un serveur de build avec Keil uVision4 (MDK-ARM), scripter une build, utiliser un makefile?

Je voudrais exécuter des builds quotidiennes, ou enregistrer / valider des builds déclenchés de projets basés sur Keil MDK-ARM. Jusqu'à présent, j'ai fait avancer les choses avec la fonction de fichier batch de l'IDE. Cela vous oblige à générer le projet au moins une fois avec l'IDE, puis à archiver le fichier de commandes et les fichiers associés .__iet ._iacréés par l'IDE.

De plus, l'EDI place de nombreuses choses spécifiques à l'utilisateur dans le fichier de commandes comme la variable Windows PATH. Cela pourrait devenir un problème avec plusieurs développeurs, car le fichier de commandes pour la construction pourrait être modifié à chaque validation d'un développeur différent.

En fin de compte, il suffit de garder une trace des différents commutateurs pour armcc , armasm et ArmLink .

Existe-t-il un moyen d'utiliser un makefile plus standard pour construire des projets Keil uVision? Existe-t-il une méthode de traduction d'un fichier de projet uVision en un script de construction plus facile à gérer?

arm compiler keil

— rmaVT
source

Je pense que c'est génial que vous implémentiez un serveur de build. Malheureusement, je n'ai aucune expérience avec le système de développement Keil, donc je ne peux pas vraiment vous aider. J'aimerais vous encourager à publier une solution si vous lorsque vous l'avez mise au point.

— semaj

Je construis des projets Keil via un script batch sans aucune dépendance PATH (autre que les outils Keil eux-mêmes) ou des fichiers __i / _ia. Pouvez-vous partager plus d'informations à ce sujet?

— Digikata

@digikata J'utilise l'option depuis l'IDE pour générer un fichier batch. Ceci est décrit dans la documentation de Keil. Il existe également une méthode basée sur la ligne de commande décrite ici , mais j'ai eu du mal à obtenir la sortie de console appropriée à partir de cette commande. La deuxième méthode démarre un nouveau processus et vous donne la possibilité de copier la fenêtre de sortie dans un fichier de sortie - pas une bonne méthode pour un serveur de build.

— rmaVT

Pour référence future, la portée de cette question se situe dans une zone de chevauchement que nous partageons avec d'autres sites Stack Exchange. Les questions sur les chaînes d'outils embarquées spécifiques comme Keil sont les bienvenues ici! Ils sont également les bienvenus sur Stack Overflow , mais n'hésitez pas à demander dans l'un ou l'autre endroit.

— Kevin Vermeer

@KevinVermeer - Oui, j'allais dire la même chose moi-même. rmaVT, vous pouvez trouver la navigation sur les questions marquées "keil" sur SO aussi éducative que les questions marquées "keil" sur EE SE .

— davidcary

Réponses:

C'est la meilleure méthode que j'ai trouvée récemment:

Dans les options de construction, sélectionnez créer un fichier de commandes.

Lorsque vous lancez une génération à partir de l'EDI, un fichier de commandes ainsi que plusieurs fichiers texte sont créés en fonction des options définies dans l'EDI. Vous devez suivre ces fichiers générés par IDE dans le contrôle de code source:

*.chauve souris
* .ini
*.__je
* ._ ia
* .lnp
* .sct

Ensuite, foo.bat peut être lancé à partir d'un script de construction.

Bien que cela crée des fichiers supplémentaires qui doivent être suivis dans le contrôle de code source si vous souhaitez créer de manière fiable à partir du fichier de commandes généré, cela supprime la nécessité de s'appuyer sur le fichier de projet Keil (foo.uvproj) et l'IDE. Je trouve plus facile de comparer les différences, et donc de suivre les modifications, dans les fichiers texte générés (* .__ i) qui contiennent des indicateurs de compilation que dans le fichier .uvproj. De plus, le fichier batch appelle directement les différents outils, armasm, armcc, armlink. Cela vous donne la sortie directe de chacune de ces étapes ainsi qu'un potentiel apparemment meilleur pour la migration d'un projet vers une chaîne d'outils différente à l'avenir si nécessaire.

Je me rends compte que cette réponse ressemble beaucoup à ma question d'origine, mais je ne connais vraiment pas de meilleure façon d'exécuter une construction scriptée avec les outils de Keil. J'ai demandé à voir ce qui pourrait arriver des autres. Je ne suis pas complètement en désaccord avec la réponse de @digikata, mais je préfère avoir des drapeaux de compilation et la carte mémoire dans un format plus facile pour le suivi et utiliser plus d'outils de style Unix pour la compilation plutôt que de lancer une compilation tout-en-un avec l'IDE. Je pense que la compilation tout-en-un de l'IDE fonctionne bien sur mon poste de travail, mais pas pour le serveur de build.

EDIT : Le serveur de build fonctionne sur Windows Server 2003. Je dois avouer que j'ai abandonné l'utilisation de l'interface de ligne de commande IDE plutôt qu'un fichier batch. Cela est devenu trop difficile à gérer.

— rmaVT
source

Une question sur ce travail - quel système d'exploitation votre serveur de build exécute-t-il? Linux, Windows 7, Windows Server 2003, Windows Server 2008?

— CrimsonX

Merci d'avoir répondu à la question! Il semble que la chaîne d'outils arm fonctionne sur Windows Server 2003 et 2008 R2 selon la documentation de Keil . Une question de suivi concernant votre modification: Comment gérez-vous les modifications apportées au fichier uvproj (par exemple en ajoutant de nouveaux fichiers dans le projet pour la compilation)? Devez-vous modifier manuellement les options de compilation dans un fichier promu sur le serveur de génération?

— CrimsonX

Vous devez placer le fichier .uvproj sous contrôle de code source. Cela fonctionne assez bien, bien que certaines préférences utilisateur restent dans le fichier malgré le fichier .userxxxxx qui est également généré. Le serveur de build a juste besoin d'ouvrir le même "projet" et de le compiler.

— rmaVT

J'appelle l'IDE Keil via la ligne de commande pour construire (pas un fichier batch généré) à partir d'un Makefile. Habituellement, il est préférable de verrouiller les fichiers de projet via la scm, ou de prendre une copie de construction de référence en renommant les noms de projet pertinents lors de cette opération.

L'IDE est parfaitement heureux de travailler avec des fichiers de projet en lecture seule, donc si vous les verrouillez, l'irritant est que vous devez les déverrouiller pour modifier les paramètres, les enregistrer et les archiver. Si vous êtes dans un environnement assez stable point dans le projet c'est assez mineur - même souhaitable.

Si vous prenez une copie de référence, la génération a tendance à se rompre lorsque les paramètres du projet changent, en particulier lorsque des fichiers de projet sont ajoutés ou supprimés de la compilation. La capture explicite de ces modifications n'est pas nécessairement mauvaise, mais est une étape supplémentaire nécessaire pour maintenir les versions.

Quoi qu'il en soit, la redirection de la sortie vers un fichier journal via l'option "-o" vous permet d'accéder au journal de sortie complet. Le journal ne sort pas une ligne à la fois, mais il semble que tout soit là. (J'analyse en fait le format d'erreur Keil en GNU fmt pour l'intégration avec l'environnement eclipse CDT. Cela me permet de passer directement aux erreurs / avertissements après la génération)

La construction en ligne de commande génère également les fichiers __i, __ia afin que ceux-ci n'aient pas non plus besoin de passer en contrôle de version pour le serveur de génération.

J'espère que cela t'aides.

— Digikata
source