Maschine spezifische Schichten in yocto

Question

Ich möchte einige Schichten holen aus Upstream für eine neue Maschine (nennen Sie es A) hauptsächlich nur, um die Maschine A konfigurieren Datei, Kernel und U-Boot von diesen Schichten bereitgestellt. Die neuen Ebenen haben jedoch mehrere bbappend-Dateien (auch mit bb-Dateien), die sich von den Ebenen anderer Maschinen in meinem yocto-Projekt unterscheiden.

Zum Beispiel Maschine A seine eigene gstreamer1.0_1.8.1.bb und bbappend Datei hat. Andere Maschinen verwenden gstreamer1.0_1.6.1.bb. Was passiert, wenn ich das Image für die andere Maschine erstelle, ist, dass es die Version 1.8.1 erstellt, weil Yocto immer nach der neuesten kompatiblen Version des Pakets sucht und diese erstellt. Die Datei gstreamer1.0_1.8.1.bapppend wird jedoch speziell für Maschine A geschrieben, gilt nicht für andere und verursacht Fehler. Nicht nur der Gstreamer, es gibt mehr.

Ich habe eine Idee wie BBLAYERS_A += "new_layers \ ..." in der Datei bblayers.conf, aber leider funktioniert es nicht so, wie ich es will.

Eine weitere Idee, die ich habe, ist, wie:

BBMASK_B = "new_layers \ ..." 
BBMASK_C = "new_layers \ ..." 
BBMASK_D = "new_layers \ ..." 
BBMASK_E = "new_layers \ ..." 
BBMASK_F = "new_layers \ ..." 
BBMASK_G = "new_layers \ ..." 
BBMASK_H = "new_layers \ ..." 
BBMASK_I = "new_layers \ ..." 
... 

Es mir nicht gut aussehen und ich bezweifle, es wird nicht so gut funktionieren. Ich denke, die Build-Prozedur ist das Laden der bblayers.conf-Datei zuerst, dann die local.conf. Daher werden die Layer bereitgestellt, bevor Sie wissen, welche Maschine erstellt wird.

Meine Frage ist, wie kann ich diese neu hinzugefügten Schichten machen, die mit Maschine arbeiten A nur, aber nicht von den anderen Maschinen gewöhnen.

Answer 1

Sie sollten versuchen, einen BSP-Layer so zu erstellen, dass er nur Effekte verursacht, wenn einer der Maschinen in diesem Layer verwendet wird.

In Ihrem Beispiel gstreamer1.0_1.8.1.bb, sollten Sie

COMPATIBLE_MACHINE = "^machinea$" 

Notiz hinzufügen, es ist ein regulärer Ausdruck, so durch die führende ^ Weglassen und endend $ können Sie ähnlich benannte Maschinen versehentlich Spiel.

Beachten Sie auch, dass ich Ihr Beispiel des Maschinennamens A in machinea geändert habe, da Maschinen kleine Buchstaben sein müssen.

Wenn Sie .bbappend Dateien hinzufügen, haben Sie sie in der Regel ändern Sie den Build von zB.

SOME_VAR_machinea 

Wenn Sie Dateien sind überschrieben, in der Regel können Sie sie in einer Struktur wie gesagt:

recipes-support/myrecipe/myrecipe/machinea/some-file 

In diesem Fall beachten Sie die zusätzliche Unterverzeichnis machinea, die sicherstellen, dass some-file nur für verwendet wird diese bestimmte Maschine.

Answer 2

Die Lösung, die für mich funktioniert, ist DISTRO Funktion von Yocto zu verwenden. Es ist flexibel. Was ich getan habe, ist die Verwendung von DISTRO für machine_A (was bedeutet, dass eine andere Konfigurationsdatei für A verwendet wird), dann ein MACHINE_A.inc mit BBMASK = "" (oder BBMASK = "layers that not for A").

In der Standard-Poky DISTRO, innerhalb der bblayers.conf-Datei, blockiere ich alle Schichten von machine_A eingeführt mit BBMASK = "all machine_A's layers".

Im local.conf, habe ich DISTRO_machine_A = "MACHINE_A", also wenn für machine_A das Bild Gebäude wird bitbake in DISTRO aussehen und die Konfigurationsdatei für machine_A finden, die die globale BBMASK zurückgesetzt Schichten zu ermöglichen, für machine_A selbst (oder sogar um andere Schichten zu blockieren).

Mit DISTRO kann ich eine separate Build-Umgebung für verschiedene Maschinen erstellen, während neue Ebenen in das Projekt eingeführt werden. Art von wie BBMASK_machine_A (BBMASK_machine_A wird nicht wirklich funktionieren, wie meine Frage beschrieben).