Ich bin Teil eines kleinen Teams (4 - 5), die an einem Embedded-Linux-Projekt arbeiten. Wir verwenden Buildroot und die Linaro Toolchain, um für unser Ziel zu bauen. Wir verwenden git für die Versionskontrolle und Jenkins für nächtliche Builds.
Das ist unser erster Versuch bei einem Projekt wie diesem und es ist mir nicht gelungen, Ressourcen zu finden, die Modelle für die Entwicklung mit dieser Art von Umgebung beschreiben.
Im Moment, nach einem nächtlichen Build, erstelle ich einen Tarball des Buildroot 'output' -Verzeichnisses, das die U-Boot-Images und das Root-Dateisystem enthält. Dies kann direkt von der Jenkins 'Archiv' Seite für den letzten erfolgreichen Build heruntergeladen werden.
Einige von uns werden an der Entwicklung auf niedrigerer Ebene arbeiten und einige an der Benutzerraumentwicklung (QT). Unser Problem ist, zu entscheiden, welcher der effizienteste / rationellste Ansatz die Entwicklung in einer solchen Umgebung ist, da die Menschen in verschiedenen Bereichen innerhalb des Projektumfangs arbeiten werden. Die Userland-Leute könnten den Tarball mit allem herunterladen und ihre Anwendungen in die Rfs integrieren, um auf dem Board zu laufen und zu debuggen, aber wie sollen wir mit der Arbeit auf der unteren Ebene der Entwicklung umgehen? Grundsätzlich, wie sollten wir die Artefakte an das Team verteilen? Ich schätze alle Gedanken sehr.
___ tag123embedded ___ Embedded bezieht sich auf eingebettete Systeme, die Bereiche wie Mikrocontroller- / DSP-Firmware-Programmierung, Echtzeitsysteme, elektronische Schnittstellen, Hardwaretreiber, serielle Buskommunikation usw. umfassen.
___ tag123kontinuierliche Integration ___ Continuous integration (CI) ist das Erstellen und automatisierte Testen des gesamten Softwareprodukts in einem häufigen Zeitplan: mindestens einmal am Tag, oft mehrmals am Tag und manchmal so oft wie nach jedem Einchecken in das Versionskontrollsystem.
___ tag123build ___ Das Konvertieren von Quellcodedateien in eigenständige Softwareartefakte, die auf einem Computer ausgeführt werden können
___ answer11185484 ___
Ich habe kürzlich einige Zeit damit verbracht, die Build-Umgebung für ein OpenEmbedded-basiertes Linux-Projekt neu zu strukturieren. Ich habe keine direkten Erfahrungen mit Buildroot, aber ich erwarte, dass OpenEmbedded dem, was Sie verwenden, ähnlich ist. Ich werde mein Setup beschreiben und mit etwas Glück finden Sie hier etwas Nützliches ...
Das Problem
Es gibt drei Softwarekomponenten, die separat installiert werden können (d. h. unabhängig voneinander): der Bootloader (u-boot); der Kernel (Linux); und das Dateisystem-Image. Unser Endprodukt wird mit einem verpackten Release dieser drei Komponenten ausgeliefert. Das heißt, eine Version von U-Boot, Linux und Dateisystem-Image, die QA-getestet wurden und von denen bekannt ist, dass sie zusammenarbeiten. Es ist jedoch möglich, eine der Komponenten unabhängig zu aktualisieren (z. B. ein neues Kernel-Image zu installieren), um eine Kombination von Softwarekomponenten zu erstellen, die nicht zusammen getestet wurden.
Dieses Problem besteht auch für Benutzerbereichsanwendungen. Sobald ein Dateisystemimage in das Ziel installiert wurde, ist es möglich, einen oder mehrere Benutzerraum-Binärdateien unabhängig von anderen Dateisystemobjekten zu aktualisieren (vorausgesetzt, Ihr Dateisystem ist nicht schreibgeschützt). Woher wissen Sie, dass die spezifische Kombination von Benutzer-Space-Anwendungen, die jetzt installiert sind, zusammenarbeiten kann? Wie kann ich sicher sein, dass die Kombination von Binärdateien, die in dieser bestimmten Einheit laufen, dieselbe Kombination von Binärdateien ist, die QA-zertifiziert wurden? Woher weiß ich, welche "Version" die Software ist?
Das andere Problem, das ich lösen musste, das gleiche Problem, das Sie in Ihrer Frage beschrieben haben, ist, wie man Entwicklern, die an verschiedenen Teilen des Software-Stacks arbeiten (Kernel, Root-Dateisystem, Qt-Apps usw.), zusammenarbeiten kann.
Eine Lösung
Ich habe dies und das "Version" -Problem folgendermaßen angesprochen:
- Speichern der rootfs und sysroot in einem Git-Repository.
- Liberale Verwendung von Git-Submodulen.
Das Speichern der root-Dateisystem- und System-Stammdateien des Ziels in einem git-Repository hat mich anfangs in die falsche Richtung gerammt (Speichern von Ausgabedateien in der Versionskontrolle, was!?!), bietet aber folgende Vorteile:
- Ein JFFS2-Dateisystem-Image (rootfs + unsere benutzerdefinierten User-Space-Anwendungen) kann so lange eingebaut werden, wie es erforderlich ist, um die User-Space-Anwendungen zu erstellen (d. h. mehrere Sekunden). Ein Entwickler muss nicht mehr zuerst die rootfs von Grund auf neu aufbauen (was bei OpenEmbedded mehrere Stunden dauert).
- Alle anderen Vorteile der Versionskontrolle (Änderungen an den rootfs können im Laufe der Zeit leicht verfolgt werden, Tags für die Veröffentlichung, Zweige usw.).
- Ich habe anfangs erwogen, die rootfs und sysroot als Tarballs zu speichern, aber ich mag die Idee von git tracking-Änderungen pro Datei.
Die Verzeichnisstruktur sieht ungefähr so aus (einige Namen wurden geändert, um Unschuldige zu schützen):
%Vor%
Jedes markierte Verzeichnis [*] ist ein Git-Repository und jedes Git-Repository ist ein Submodul seines Elternteils.
Die Build-Umgebung wird von einem Makefile der obersten Ebene initialisiert, das im Wesentlichen eine rekursive %code% und %code% verwendet. Alle Entwickler würden tun:
%Vor%
Ein User-Space-Entwickler kann dann sofort erstellen:
%Vor%
Der Maintainer des Dateisystems kann rootfs aktualisieren:
%Vor%
Software Versionierung
Vom Makefile der obersten Ebene ( %code% ) ist es möglich, alle Softwarekomponenten (Kernel, U-Boot, Dateisystem-Image) zu erstellen. Mit den folgenden git-Befehlen exportiert das Makefile an alle Sub-make-Prozesse eine einzige Umgebungsvariable (z. B. %code% ), die die aktuelle Softwareversion beschreibt. Die Version ist entweder ein Tag aus dem Git-Repository oder ein SHA (z. B. %code% , %code% oder %code% ).
%Vor%
Wenn sogar eine einzelne Datei in einem der Unterverzeichnisse des Projekts geändert wurde, dann ist %code% immer %code% . Diese einzelne Variable %code% wird dann als Kompilierzeitkonstante an alle Builds übergeben (U-Boot-, Kernel-, Userspace-Anwendungen usw.).
Zur Laufzeit akkumuliert eine benutzerdefinierte Benutzerbereichsanwendung die %code% -Werte aller Komponenten, und wenn sie alle denselben Wert melden, wird diese Zeichenfolge zur offiziellen Version, die vom Produkt gemeldet wird. Wenn sich auch nur ein %code% -Wert von den anderen unterscheidet, dann wurde der Software-Stack nicht aus dem gleichen SHA der obersten Ebene erstellt und kann nicht in die Wildnis entlassen werden (zu QA zum Testen, zur Produktion für die Herstellung usw.).
Wenn eine Softwarekomponente nicht aus dem Makefile der obersten Ebene (z. B. %code% ) erstellt wird, ist die %code% für diese Komponente undefiniert und der resultierende Softwarestapel für "nur interne Verwendung". Das heißt, eine "Freigabe" aller Softwarekomponenten kann nur durch den Aufbau aus dem Makefile der obersten Ebene erfolgen.
Als Referenz meldet Linux %code% über eine benutzerdefinierte Datei in procfs, u-boot-Berichte über die Linux-Befehlszeile ( %code% ) und jede Benutzerbereichsanwendung über Interprozesskommunikation.
Zusammenfassung
Ein Vorbehalt.Ich habe diese Build-Umgebung erst vor einem Monat entwickelt, kann also keine Behauptungen für ihre Robustheit machen, aber für den Moment scheint es zusammenzuhalten ...
Wenn Sie bestimmte Fragen oder Punkte haben, die Sie klären möchten, werde ich gerne meine Antwort aktualisieren.
___ tag123jenkins ___ Jenkins ist ein Open-Source-Tool für die kontinuierliche Integration, das in Java geschrieben wurde und Pakete für Linux, Mac OS X, Windows, FreeBSD und OpenBSD enthält. Das Projekt wurde von Hudson abgezweigt.
___ tag123linux ___ LINUX FRAGEN MÜSSEN PROGRAMMIEREN VERWANDT SEIN. Verwenden Sie dieses Tag nur, wenn sich Ihre Frage auf das Programmieren mit Linux-APIs oder das Linux-spezifische Verhalten bezieht, nicht nur, weil Sie Ihren Code unter Linux ausführen. Wenn Sie Linux-Unterstützung benötigen, können Sie https://unix.stackexchange.com oder https://askubuntu.com ausprobieren
___