Wie kann ich einen Build-Server mit Keil uVision4 (MDK-ARM) verwenden, ein Skript für einen Build erstellen und ein Makefile verwenden?

13

Ich möchte tägliche Builds ausführen oder durch Einchecken / Festschreiben ausgelöste Builds von Keil MDK-ARM-basierten Projekten. Bisher habe ich die Batch-Datei-Funktion der IDE in Schwung gebracht. Dazu müssen Sie das Projekt mindestens einmal mit der IDE erstellen und dann die Batchdatei sowie die zugehörigen .__iund ._iavon der IDE erstellten Dateien einchecken .

Darüber hinaus fügt die IDE viele benutzerspezifische Dinge in die Batch-Datei ein, z. B. die Windows-Variable PATH. Dies kann bei mehreren Entwicklern zu einem Problem werden, da die zu erstellende Batchdatei bei jedem Commit eines anderen Entwicklers geändert werden kann.

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?

rmaVT
quelle
Ich finde es toll, dass Sie einen Build-Server implementieren. Leider habe ich keine Erfahrung mit dem Keil-Entwicklungssystem, daher kann ich Ihnen nicht wirklich weiterhelfen. Ich möchte Sie dazu ermutigen, eine Lösung zu veröffentlichen, wenn Sie diese erhalten.
Semaj
Ich erstelle Keil-Projekte über ein Stapelskript ohne PATH-Abhängigkeiten (mit Ausnahme der Keil-Tools selbst) oder __i / _ia-Dateien. Können Sie weitere Informationen dazu mitteilen?
Digikata
1
@digikata Ich benutze die Option in der IDE, um eine Batch-Datei zu generieren. Dies ist in Keils Dokumentation beschrieben. Es gibt auch eine befehlszeilengesteuerte Methode, die hier beschrieben wird , 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 Buildserver.
RMAVT
Zum späteren Nachschlagen liegt der Umfang dieser Frage in einem Bereich, der sich mit anderen Stack Exchange-Sites überschneidet. Fragen zu Embedded-spezifischen Toolchains wie Keil sind hier definitiv willkommen! Sie sind auch bei Stack Overflow willkommen , können jedoch an beiden Stellen nachfragen.
Kevin Vermeer
1
@ KevinVermeer - Ja, ich wollte das Gleiche selbst sagen. rmaVT, Sie können das Durchsuchen der Fragen mit dem Tag "keil" auf SO genauso lehrreich finden wie die Fragen mit dem Tag "keil" auf EE SE .
Davidcary

Antworten:

8

Dies ist die beste Methode, die ich mir in letzter Zeit ausgedacht habe:

Wählen Sie in den Erstellungsoptionen die Option Stapeldatei erstellen aus.

Wenn Sie einen Build von der IDE aus starten, werden eine Batch-Datei und mehrere Textdateien basierend auf den in der IDE festgelegten Optionen erstellt. Sie müssen diese IDE-generierten Dateien in der Quellcodeverwaltung nachverfolgen:

  • *.Schläger
  • * .ini
  • *.__ich
  • * ._ ia
  • * .lnp
  • * .sct

Dann kann foo.bat über ein Build-Skript gestartet werden.

Auf diese Weise 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. Sie müssen jedoch nicht mehr auf die Keil-Projektdatei (foo.uvproj) und die IDE angewiesen sein. Ich finde es einfacher, Unterschiede zu den generierten Textdateien (* .__ i), die Compiler-Flags enthalten, zu vergleichen und damit Änderungen nachzuverfolgen, als zur .uvproj-Datei. Darüber hinaus werden in der Batchdatei die verschiedenen Tools armasm, armcc, armlink direkt aufgerufen. Dies gibt Ihnen die direkte Ausgabe jedes dieser Schritte sowie ein anscheinend besseres Potenzial, um ein Projekt in Zukunft bei Bedarf auf eine andere Toolkette zu migrieren.

Mir ist klar, dass sich diese Antwort sehr nach meiner ursprünglichen Frage anhört, aber ich kenne wirklich keinen besseren Weg, um einen skriptbasierten Build mit Keils Werkzeugen auszuführen. Ich fragte nach, 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 Verfolgen zu haben und mehr Tools im Unix-Stil zum Kompilieren zu verwenden, anstatt eine All-in-One-Kompilierung zu starten mit der IDE. Ich denke, dass die All-in-One-Kompilierung aus der IDE auf meiner Workstation gut funktioniert, aber nicht für den Buildserver.

BEARBEITEN : Der Build-Server wird unter Windows Server 2003 ausgeführt. Ich muss gestehen, dass ich es nicht gewohnt bin, die IDE-Befehlszeilenschnittstelle anstelle einer Batchdatei zu verwenden. Dies war einfach zu schwierig zu handhaben.

rmaVT
quelle
Eine Frage zu dieser Arbeit - unter welchem ​​Betriebssystem läuft Ihr Build-Server? Linux, Windows 7, Windows Server 2003, Windows Server 2008?
CrimsonX am
Vielen Dank für die Beantwortung der Frage! Die Arm-Toolchain funktioniert anscheinend unter Windows Server 2003 und 2008 R2 gemäß Keils Dokumentation . Eine weitere Frage zu Ihrer Bearbeitung: Wie gehen Sie mit Änderungen an der uvproj-Datei um (z. B. Hinzufügen neuer Dateien zum Kompilierungsprojekt)? Müssen Sie die Kompilierungsoptionen in einer auf den Build-Server hochgestuften Datei manuell ändern?
CrimsonX
Sie müssen die .uvproj-Datei der Quellcodeverwaltung unterstellen. Dies funktioniert ziemlich gut, obwohl einige Benutzereinstellungen trotz der ebenfalls generierten .userxxxxx-Datei in der Datei verbleiben. Der Build-Server muss nur dasselbe "Projekt" öffnen und es erstellen.
rmaVT
3

Ich rufe die Keil IDE über die Kommandozeile auf, um aus einem Makefile heraus (keine generierte Batch-Datei) zu erstellen. In der Regel ist es besser, die Projektdateien über den SCM zu sperren oder eine Referenzerstellungskopie zu erstellen, in der die entsprechenden Projektnamen umbenannt werden.

Die IDE arbeitet sehr gerne mit schreibgeschützten Projektdateien. Wenn Sie diese also sperren, müssen Sie sie entsperren, um Einstellungen zu ändern, sie 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, wird der Build in der Regel unterbrochen, wenn sich die Projekteinstellungen ändern. Dies gilt insbesondere, wenn Projektdateien der Kompilierung hinzugefügt oder daraus entfernt werden. Das explizite Erfassen dieser Änderungen ist nicht unbedingt schlecht, aber ein zusätzlicher Schritt zum Verwalten von Builds erforderlich.

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 einzeln ausgegeben, aber es scheint alles vorhanden zu sein. (Ich analysiere das Keil-Fehlerformat in GNU fmt, um es in die Eclipse-CDT-Umgebung zu integrieren. Dadurch kann ich nach dem Build direkt zu Fehlern / Warnungen springen.)

Die Befehlszeilenerstellung generiert auch die Dateien __i, __ia, sodass diese auch nicht in die Versionskontrolle für den Erstellungsserver einsteigen müssen.

Hoffe das hilft.

Digikata
quelle