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

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?

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.

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.