Grundsätzlich richten sich die rust_*
-Moduldefinitionen nach
Nutzung und Erwartungen von cc_*
. Im Folgenden finden Sie ein Beispiel für ein Modul,
Definition für ein Rust-Binärprogramm:
rust_binary {
name: "hello_rust",
crate_name: "hello_rust",
srcs: ["src/hello_rust.rs"],
host_supported: true,
}
Auf dieser Seite werden die häufigsten Attribute für rust_*
-Module behandelt. Für
zu bestimmten Modultypen und Beispielmoduldefinitionen,
Siehe
Binärmodule
Bibliotheksmodule,
oder
Testmodule
Grundlegende Modultypen
Typ | Definition | Weitere Informationen |
---|---|---|
rust_binary | Ein Rust-Binärprogramm | Binärmodule Seite |
rust_library | Erzeugt eine Rust-Bibliothek und stellt sowohl rlib als auch
dylib Varianten. |
rust_library ,
Seite „Bibliotheksmodule“. |
rust_ffi | Erzeugt eine Rust-C-Bibliothek, die über Cc verwendet werden kann Module und bietet sowohl statische als auch gemeinsam genutzte Varianten. | rust_ffi ,
Seite „Bibliotheksmodule“ |
rust_proc_macro | Erstellt eine proc-macro -Rust-Bibliothek.
Sie sind analog zu Compiler-Plug-ins. |
rust_proc_macro ,
Seite „Bibliotheksmodule“ |
rust_test | Erzeugt eine Rust-Testbinärdatei mit dem Standard-Rust-Test-Harnisch. | Seite Module testen |
rust_fuzz | Erzeugt eine Rust-Fuzz-Binärdatei mithilfe der
libfuzzer |
Beispiel für das Modul rust_fuzz |
rust_protobuf | Generiert eine Quelle und erstellt einen Rust-Wert -Bibliothek, die eine Schnittstelle für einen bestimmten protobuf bereitstellt. | Seiten Protobufs-Module und Source Generators |
rust_bindgen | Generiert eine Quelle und erstellt einen Rust-Bibliothek mit Rust-Bindungen an C-Bibliotheken. | Bindgen-Bindungsmodule und Source Generators |
Wichtige allgemeine Eigenschaften
Diese Eigenschaften sind bei allen Android Rost-Produkten gleich. Module. Alle zusätzlichen (eindeutigen) Eigenschaften, die mit einzelnen Rust-Module sind auf der Seite des jeweiligen Moduls aufgeführt.
Name
name
ist der Name Ihres Moduls. Wie bei anderen Soong-Modulen muss auch dieser Name eindeutig sein
für die meisten Android.bp
-Modultypen. Standardmäßig wird name
als Ausgabe verwendet
filename. Wenn sich der Name der Ausgabedatei vom Modulnamen unterscheiden muss, verwenden Sie die Methode
stem
, um sie zu definieren.
Stamm
stem
(optional) bietet direkte Kontrolle über den Ausgabedateinamen (außer
die Dateiendung und andere Suffixe). Beispiel: rust_library_rlib
mit dem Stammwert libfoo
erstellt eine libfoo.rlib
-Datei. Wenn Sie
keinen Wert für das Attribut stem
angeben, verwendet der Ausgabedateiname den
Modulnamen.
Verwenden Sie die Funktion stem
, wenn Sie den Modulnamen nicht auf die gewünschte Ausgabe festlegen können
filename. Die rust_library
für die Kiste log
heißt z. B.
liblog_rust
,
weil ein liblog cc_library
existiert bereits. Mit dem Attribut stem
wird in diesem Fall sichergestellt, dass die Ausgabe
Die Datei heißt liblog.*
statt liblog_rust.*
.
„srcs“
srcs
enthält eine einzelne Quelldatei, die den Einstiegspunkt für Ihren
Modul (normalerweise main.rs
oder lib.rs
). rustc
übernimmt die Auflösung und
Erkennung aller anderen für die Kompilierung erforderlichen Quelldateien.
die in der erstellten Datei deps
aufgezählt werden.
Vermeiden Sie diese Verwendung von Plattformcodes nach Möglichkeit. Siehe Quellgeneratoren .
kiste_name
crate_name
legt die Metadaten für den Kistennamen über das rustc
---crate_name
fest.
. Bei Modulen, die Bibliotheken generieren, muss dies mit den erwarteten
der in der Quelle verwendet wird. Wenn z. B. auf das Modul libfoo_bar
verwiesen wird,
in der Quelle als extern crate foo_bar
angezeigt wird, muss dies so aussehen:
crate_name: „foo_bar“.
Dieses Attribut ist für alle rust_*
-Module gleich, aber für Module erforderlich.
die Rust-Bibliotheken wie rust_library
rust_ffi
, rust_bindgen
, rust_protobuf
und rust_proc_macro
). Diese
Module erzwingen rustc
-Anforderungen in Bezug auf die Beziehung zwischen crate_name
und den Namen der Ausgabedatei. Weitere Informationen finden Sie in der
Bibliotheksmodule
.
Lint
Rustc Linter wird standardmäßig für alle Modultypen außer Quellgeneratoren ausgeführt. Einige Lint-Sets definiert und zur Validierung der Modulquelle verwendet. Mögliche Werte für solches Lint lautet:
default
ist der Standardsatz von Lints, abhängig vom Speicherort des Modulsandroid
ist der strengste Lint-Satz, der für den gesamten Android-Plattformcode giltvendor
einen gelockerten Satz von Lints auf den Anbietercode angewendetnone
, um alle Lint-Warnungen und -Fehler zu ignorieren
Clippy_lints
Der clippy Linter ist ebenfalls wird standardmäßig für alle Modultypen außer Quellgeneratoren ausgeführt. Einige Arten von Fusseln definiert, die zur Validierung der Modulquelle verwendet werden. Dies sind einige Werte:
default
-Standardsatz von Lints je nach Modulstandortandroid
ist der strengste Lint-Satz, der für den gesamten Android-Plattformcode giltvendor
einen gelockerten Satz von Lints auf den Anbietercode angewendetnone
, um alle Lint-Warnungen und -Fehler zu ignorieren
Ausgabe
edition
definiert die Rust-Edition, die für
bei der Kompilierung dieses Codes. Dies entspricht den Standardversionen für C und C++. Gültige Werte
sind 2015
und 2018
(Standardeinstellung).
Flags
flags
enthält eine Stringliste mit Flags, die während der Kompilierung an rustc
übergeben werden.
ld_flags
ld-flags
enthält eine Stringliste mit Flags, die beim Kompilieren an den Linker übergeben werden sollen
Quelle. Diese werden mit dem Rustc-Flag -C linker-args
übergeben. clang
wird verwendet als
das Verknüpfungs-Frontend, wobei lld
für die eigentliche Verknüpfung aufgerufen wird.
Funktionen
features
ist eine Stringliste von Funktionen, die während der Kompilierung aktiviert werden müssen.
Wird von --cfg 'feature="foo"'
an Rustc übergeben. Die meisten Funktionen sind additiv,
In vielen Fällen besteht dies aus allen Funktionen, die von allen abhängigen
Module. In Fällen, in denen sich Funktionen jedoch gegenseitig ausschließen,
Zusätzliche Module in allen Build-Dateien definieren, die in Konflikt stehende Funktionen bereitstellen.
cfgs
cfgs
enthält eine Stringliste mit cfg
-Flags, die während der Kompilierung aktiviert werden müssen.
Diese wird von --cfg foo
und --cfg "fizz=buzz"
an rustc
übergeben.
Das Build-System legt automatisch bestimmte cfg
-Flags fest,
(siehe unten):
Für Module, die als Dylib erstellt werden, ist die cfg-Datei
android_dylib
festgelegt.Für Module, die das VNDK verwenden, wird die cfg-Datei
android_vndk
festgelegt. Dies ist ähnlich wie__ANDROID_VNDK__
Definition für C++.
strip
strip
steuert, ob und wie die Ausgabedatei entfernt wird (falls zutreffend).
Ist die Richtlinie nicht konfiguriert, werden von den Gerätemodulen standardmäßig alles außer den Mini-Informationen zur Fehlerbehebung entfernt.
Bei Hostmodulen werden standardmäßig keine Symbole entfernt. Gültige Werte sind none
, um das Entfernen zu deaktivieren, und all
, um alles zu entfernen, einschließlich der Mini-Informationen zur Fehlerbehebung.
Weitere Werte finden Sie in der
Referenz zu Soong-Modulen
host_supported
Bei Gerätemodulen gibt der Parameter host_supported
an, ob das Modul
sollte auch eine Hostvariante angegeben werden.
Bibliotheksabhängigkeiten definieren
Rust-Module können sowohl von CC als auch von Rust-Bibliotheken anhand der folgenden Attribute:
Name der Property | Beschreibung |
---|---|
rustlibs |
Liste der rust_library -Module, die auch Abhängigkeiten sind. Verwenden als
Ihre bevorzugte Methode zum Deklarieren von Abhängigkeiten.
wählen Sie die gewünschte Verknüpfung aus. Weitere Informationen finden Sie unten im Abschnitt Beim Verknüpfen mit Rust-Bibliotheken. |
rlibs |
Liste der rust_library Module, die statisch verknüpft werden müssen
als rlibs . (Mit Vorsicht zu verwenden; siehe
Bei Verknüpfungen mit Rust-Bibliotheken (siehe unten) |
shared_libs |
Liste der cc_library -Module, die dynamisch sein müssen
als geteilte Fotogalerien verknüpft. |
static_libs |
Liste der cc_library -Module, die statisch sein müssen
als statische Bibliotheken verknüpft. |
whole_static_libs |
Liste der cc_library -Module, die statisch sein sollten
als statische Bibliotheken verknüpft und als Ganzes in die resultierende Bibliothek aufgenommen. Für
rust_ffi_static Varianten, whole_static_libraries werden in der
das daraus entstandene statische Bibliotheksarchiv. Für rust_library_rlib Varianten,
whole_static_libraries Bibliotheken werden in die resultierende rlib gebündelt
Bibliothek.
|
Beim Verknüpfen von Rust-Bibliotheken als
Best Practice ist, die Eigenschaft rustlibs
anstelle von rlibs
zu verwenden.
dylibs
, es sei denn, es gibt dafür einen besonderen Grund. Dadurch kann der Build
je nachdem, was das Stammmodul erfordert,
und verringert die Wahrscheinlichkeit, dass ein Abhängigkeitsbaum sowohl rlib
als auch
dylib
-Versionen einer Bibliothek (wodurch die Kompilierung fehlschlägt).
Nicht unterstützte und eingeschränkte Support-Build-Funktionen
Rust von Soong bietet eingeschränkte Unterstützung für vendor
und
vendor_ramdisk
Images und Snapshots. staticlibs
, cdylibs
,
rlibs
und binaries
werden unterstützt. Für die Erstellungsziele von Anbieter-Images
Die Property android_vndk
cfg
ist festgelegt. Sie können dies im Code verwenden,
zwischen System- und Anbieterzielen. rust_proc_macros
sind nicht
im Rahmen von Anbieter-Snapshots erfasst; Wenn diese davon abhängen,
eine entsprechende
Versionskontrolle.
Produkt-, VNDK- und Wiederherstellungs-Images werden nicht unterstützt.
Inkrementelle Builds
Entwickler können die inkrementelle Kompilierung
Rust-Quelle durch Festlegen des SOONG_RUSTC_INCREMENTAL
Umgebungsvariable auf true
.
Warnung: Es wird nicht garantiert, dass Sie Binärdateien erstellen, die mit den die von Buildbots generiert wurden. Die Adressen von Funktionen oder Daten, die in der können abweichen. Um sicherzustellen, dass die generierten Artefakte 100 % sind die mit denen der EngProd-Infrastruktur identisch sind, lassen Sie diesen Wert nicht.