Nun fehlt noch das eigentliche Embedded-Build-System, also Tools, um das Betriebssystem mit all seinen Bestandteilen zu konfigurieren, zu übersetzen und für das Targetsystem aufzubereiten. Ein Großteil dieser Aufgaben wird bei Yocto durch »bitbake« erledigt, einem Python Script, das alle Aufgaben der Erstellung eines kompletten BSP mit Bootloader, Kernel und Root-Filesystem zentral vereint. Es handelt sich um ein komplexes, erweiterbares Task-Management und Scheduling-Tool, das automatisch die Abhängigkeiten zwischen einzelnen Tasks feststellt und diese in der korrekten Reihenfolge und – soweit möglich – parallel ausführt sowie deren korrekte Ausführung überwacht.
Die einzelnen Tasks für jedes Paket leiten sich von der manuellen Vorgehensweise zur Installation von Paketen ab. Zunächst einmal muss der Source-Code heruntergeladen werden (Kommando: do_fetch). Yocto erlaubt das Laden von Quellpaketen u.a. mit http, ftp, git oder von lokalen Verzeichnissen. Diese Quellpakete werden in einem Download-Verzeichnis gespeichert, so dass sie für zukünftige Builds lokal zur Verfügung stehen. Anschließend muss das Paket entpackt werden (Kommando do_unpack), falls nötig gepatcht (do_patch) und gegebenenfalls konfiguriert (do_configure). Im nächsten Schritt wird das Paket nach Anweisung übersetzt und gelinkt (do_compile) und in einem temporären Verzeichnisbaum installiert (do_install).
Nach Abschluss dieser Prozesse für jedes benötigte Paket wird dieser Verzeichnisbaum inklusive Kernel und gegebenenfalls Bootloader in ein Image verpackt, das dann z.B. direkt auf eine SD-Karte oder ins Flash des Zielsystems geschrieben werden kann. Dazu unterstützt Yocto verschiedene File-Systeme.
Während ein vollständiger Build eines Targetsystems einige Stunden dauert und etliche Gigabyte an Speicherplatz verschlingt, relativiert sich der Aufwand beim nächsten Build. Dann werden nur die Tasks wiederholt ausgeführt, die notwendig sind. Auch eine Internet-Verbindung ist nicht mehr erforderlich, da mit der lokalen Kopie der Paketquellen gearbeitet wird. Veränderungen an Sourcecode und Konfigurationsdaten detektiert Yocto durch Überprüfungen von Checksummen und Datecodes.
Grafische Unterstützung
Bitbake und seine Helfer-Scripte erlauben eine schnelle und reibungslose Steuerung des gesamten Build-Prozesses, benötigen allerdings etwas Eingewöhnungszeit; manchmal ist eine grafische Analyse der Build-Projektes effektiver als das Durchsuchen von Konfigurationsdateien.
Daher wurde ab Yocto Version 1.8 »Toaster« als Web-Interface zur Konfiguration, Steuerung und Analyse von Builds auf lokalen Systemen und Build-Servern eingeführt. Toaster unterstützt dazu zwei verschiedene Modi: den Analyse- und den Build-Modus. Der Analyse-Modus erlaubt die grafische Überwachung und Analyse einzelner, durch bitbake von der Kommandozeile aus gestarteter Builds und liefert Informationen über den Stand des Build-Prozesses inklusive Rechenzeit, aufgetretene Fehler, zugrundegelegte Konfigurationen sowie eine detaillierte Analyse gebauter Pakete. Diese reicht von Abhängigkeitsanalysen zwischen Layern, Rezepten und Tasks bis hin zu Informationen über die dem Paket zugrunde liegende Lizenzen.
Der Build-Modus erlaubt zusätzlich die Konfiguration und Planung von Builds einschließlich deren zeitlicher Terminierung direkt über das Web-Interface. Er ermöglicht eine interaktive Konfiguration der verwendeten Layer, Zielplattform und gesetzter Konfigurationsvariablen. Ein wichtiges Feature ist das interaktive Durchsuchen öffentlicher Verzeichnisse nach Layern, die beispielsweise ein bestimmtes Paket zur Verfügung stellen. Toaster importiert dann, wie in Bild 2 dargestellt, die erforderlichen Layer automatisch und löst auch Abhängigkeiten zwischen Pakten und Layern automatisch auf.
Unabhängig vom gewünschten Modus erlaubt Toaster sowohl die lokale Installation als auch eine Installation als Service. Die lokale Installation ist für einzelne Entwickler oder Tests nutzbar. Die dezentrale Installation als Service sieht einen Mehrbenutzerbetrieb vor und ist damit für Arbeitsgruppen und Firmen für den Aufbau abgesetzter Build-Server inter¬essant. Dabei können die einzelnen Services wie HTTP-Server, Datenbank und die eigentlichen Build-Systeme sogar auf verschiedene Server verteilt werden (Bild 3).
Toaster ermöglicht das Anlegen von Projekten mit jeweils einem oder mehreren Builds. Nachdem ein neues Projekt angelegt wurde, wird zuerst die Maschinenkonfiguration ausgewählt. Im einfachsten Fall wird nur noch ein passendes Image-Rezept ausgewählt und schon kann der Build-Prozess gestartet werden. Im nächsten Schritt können zusätzliche Software-Pakete über Hinzufügen der notwendigen Rezepte als weitere Builds angehängt werden. Für die Arbeit mit Toaster wird meist auf vorgefertigte Layer zurückgegriffen. Es ist allerdings auch eine Erweiterung um eigene Layer vorgesehen, z.B. für firmeninterne BSPs und Konfigurationen.
Ein durch Toaster gestarteter Build unterscheidet sich im Endergebnis nicht von einem durch bitbake manuell durchgeführten. Alle Log Files, Image Files und temporären Dateien finden sich am gewohnten Ort in der Yocto-Verzeichnisstruktur, sodass jederzeit ein Übergang zur Kommandozeile möglich ist.
Yocto ist derzeit bei etwa 120 Kunden der Avnet Memec Silica als Build-System für unterschiedlichste Anwendungen im Einsatz. Erfahrungswerte belegen, dass Kunden nach der Einarbeitung damit besser zurechtkommen als mit ihren vorherigen Systemen. Der strukturierte und einheitliche Ansatz hilft Entwicklungsteams projektübergreifend zusammenzuarbeiten und ermöglicht systematischen Re-use bei aufeinander aufbauenden Projekten. Einzig die Anforderungen an den Build-Rechner machen oft eine Neuinvestition erforderlich, oftmals verbunden mit dem Aufbau einiger zentraler Build-Server.
Über die Autoren:
Martin Hecht und Michael Röder arbeiten als Field Application Engineers bei Avnet Memec Silica.