Wie kann ich einen Build-Server mit Keil uVision4 (MDK-ARM) verwenden, einen Build scripten, ein Makefile verwenden?

Ich möchte tägliche Builds ausführen oder getriggerte Builds von Keil MDK-ARM-basierten Projekten einchecken/commiten. Bisher habe ich die Dinge mit der Stapeldateifunktion der IDE in Gang gebracht. Dazu müssen Sie das Projekt mindestens einmal mit der IDE erstellen und dann die Batchdatei und die zugehörigen .__iund ._iavon der IDE erstellten Dateien einchecken.

Darüber hinaus fügt die IDE viele benutzerspezifische Dinge in die Batchdatei ein, z. B. die Windows-PATH-Variable. Dies könnte bei mehreren Entwicklern zu einem Problem werden, da die Batchdatei zum Erstellen bei jedem Commit von einem anderen Entwickler geändert werden könnte.

Letztendlich muss man nur die verschiedenen Schalter für armcc , armasm und ArmLink im Auge behalten .

Gibt es eine Möglichkeit, ein Standard-Makefile zum Erstellen von Keil uVision-Projekten zu verwenden? Gibt es eine Methode zum Übersetzen einer uVision-Projektdatei in ein besser wartbares Build-Skript?

Ich finde es großartig, dass Sie einen Build-Server implementieren. Leider habe ich keine Erfahrung mit dem Keil-Entwicklungssystem, daher kann ich Ihnen nicht wirklich helfen. Ich möchte Sie ermutigen, eine Lösung zu posten, wenn Sie, wenn Sie es geklappt haben.
Ich erstelle Keil-Projekte per Batch-Skript ohne PATH-Abhängigkeiten (außer zu den Keil-Tools selbst) oder __i / _ia-Dateien. Können Sie weitere Informationen dazu teilen?
@digikata Ich verwende die Option in der IDE, um eine Batchdatei zu generieren. Dies ist in der Dokumentation von Keil beschrieben. Es gibt auch eine hier beschriebene befehlszeilengesteuerte Methode , aber ich hatte Schwierigkeiten, die richtige Konsolenausgabe von diesem Befehl zu erhalten. Die zweite Methode startet einen neuen Prozess und gibt Ihnen die Möglichkeit, das Ausgabefenster in eine Ausgabedatei zu kopieren – keine gute Methode für einen Build-Server.
Für zukünftige Referenzen liegt der Umfang dieser Frage in einem Überschneidungsbereich, den wir mit anderen Stack Exchange-Sites teilen. Fragen zu embedded-spezifischen Toolchains wie Keil sind hier auf jeden Fall willkommen! Sie sind auch auf Stack Overflow willkommen , aber fragen Sie ruhig an beiden Stellen.
@KevinVermeer – Ja, das wollte ich auch gerade sagen. rmaVT, können Sie feststellen, dass Sie die mit "keil" gekennzeichneten Fragen auf SO genauso lehrreich durchsuchen wie die mit "keil" gekennzeichneten Fragen auf EE SE .

Antworten (2)

Dies ist die beste Methode, die mir in letzter Zeit eingefallen ist:

Wählen Sie in den Build-Optionen Batch-Datei erstellen aus.

Wenn Sie einen Build von der IDE aus starten, wird basierend auf den in der IDE festgelegten Optionen eine Stapeldatei zusammen mit mehreren Textdateien erstellt. Sie müssen diese von der IDE generierten Dateien in der Quellcodeverwaltung nachverfolgen:

  • *.Schläger
  • *.ini
  • *.__ich
  • *._ia
  • *.lnp
  • *.sct

Dann kann foo.bat von einem Build-Skript aus gestartet werden.

Dadurch werden zwar zusätzliche Dateien erstellt, die in der Quellcodeverwaltung nachverfolgt werden müssen, wenn Sie zuverlässig aus der generierten Batchdatei erstellen möchten, es entfällt jedoch die Notwendigkeit, sich auf die Keil-Projektdatei (foo.uvproj) und die IDE zu verlassen. Ich finde es einfacher, Unterschiede zu vergleichen und somit Änderungen zu den generierten Textdateien (*.__i) zu verfolgen, die Compiler-Flags enthalten, als zur .uvproj-Datei. Außerdem ruft die Batch-Datei direkt die verschiedenen Tools armasm, armcc, armlink auf. Dies gibt Ihnen die direkte Ausgabe jedes dieser Schritte sowie ein scheinbar besseres Potenzial für die zukünftige Migration eines Projekts auf eine andere Toolkette, falls erforderlich.

Mir ist klar, dass diese Antwort sehr nach meiner ursprünglichen Frage klingt, aber ich kenne wirklich keine bessere Möglichkeit, einen Skript-Build mit den Tools von Keil auszuführen. Ich bat darum, zu sehen, was von anderen kommen könnte. Ich bin mit der Antwort von @digikata nicht ganz einverstanden, aber ich bevorzuge es, Compiler-Flags und die Speicherzuordnung in einem einfacheren Format zum Nachverfolgen zu haben und mehr Tools im Unix-Stil für die Kompilierung zu verwenden, anstatt eine All-in-One-Kompilierung zu starten mit der IDE. Ich denke, die All-in-One-Kompilierung aus der IDE funktioniert gut auf meiner Workstation, aber nicht für den Build-Server.

BEARBEITEN : Der Build-Server läuft auf Windows Server 2003. Ich muss gestehen, dass ich auf die Verwendung der IDE-Befehlszeilenschnittstelle statt einer Batch-Datei verzichtet habe. Dies wurde einfach zu schwierig zu handhaben.

Eine Frage zu dieser Arbeit - welches Betriebssystem läuft auf Ihrem Build-Server? Linux, Windows 7, Windows Server 2003, Windows Server 2008?
Danke für die Beantwortung der Frage! Sieht so aus, als ob die Arm-Toolchain auf Windows Server 2003 & 2008 R2 gemäß der Dokumentation von Keil funktioniert . Eine Folgefrage zu Ihrer Bearbeitung: Wie gehen Sie mit Änderungen an der uvproj-Datei um (z. B. Hinzufügen einer neuen Datei zum Kompilieren in das Projekt)? Müssen Sie die Kompilierungsoptionen in einer Datei, die auf den Build-Server hochgestuft wurde, manuell ändern?
Sie müssen die .uvproj-Datei unter Quellcodeverwaltung stellen. Das funktioniert ziemlich gut, obwohl trotz der ebenfalls generierten .userxxxxx-Datei noch einige Benutzereinstellungen in der Datei verbleiben. Der Build-Server muss nur dasselbe "Projekt" öffnen und es erstellen.

Ich rufe die Keil-IDE über die Befehlszeile auf, um (keine generierte Batch-Datei) aus einem Makefile heraus zu erstellen. Normalerweise funktioniert es besser, die Projektdateien über den scm zu sperren oder eine Referenz-Build-Kopie zu nehmen und dabei die relevanten Projektnamen umzubenennen.

Die IDE arbeitet gerne mit schreibgeschützten Projektdateien. Wenn Sie sie also sperren, müssen Sie sie entsperren, um Einstellungen zu ändern, zu speichern und wieder einzuchecken. Wenn Sie ziemlich stabil sind Punkt im Projekt ist dies ziemlich gering - sogar wünschenswert.

Wenn Sie eine Referenzkopie erstellen, neigt der Build dazu, zu brechen, wenn sich die Projekteinstellungen ändern – insbesondere wenn Projektdateien hinzugefügt oder aus der Kompilierung entfernt werden. Das explizite Erfassen dieser Änderungen ist nicht unbedingt schlecht, aber es ist ein zusätzlicher Schritt, der zum Verwalten von Builds erforderlich ist.

In beiden Fällen können Sie durch Umleiten der Ausgabe in eine Protokolldatei über die Option "-o" auf das vollständige Ausgabeprotokoll zugreifen. Das Protokoll wird nicht zeilenweise ausgegeben, aber es scheinen alle vorhanden zu sein. (Ich parse das Keil-Fehlerformat tatsächlich in GNU fmt für die Integration in die Eclipse-CDT-Umgebung. Dadurch kann ich nach dem Build direkt zu Fehlern/Warnungen springen.)

Der Befehlszeilen-Build generiert auch die __i-, __ia-Dateien, sodass diese auch nicht in die Versionskontrolle für den Build-Server gehen müssen.

Hoffe das hilft.

Wie kann ich einen Build-Server mit Keil uVision4 (MDK-ARM) verwenden, einen Build scripten, ein Makefile verwenden?
AntwortenHierDatenschutz-Bestimmungen1y, 0v