Android Rust-Module

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

TypDefinitionWeitere Informationen
rust_binaryEin Rust-Binärprogramm Binärmodule Seite
rust_libraryErzeugt eine Rust-Bibliothek und stellt sowohl rlib als auch dylib Varianten. rust_library, Seite „Bibliotheksmodule“.
rust_ffiErzeugt 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_macroErstellt eine proc-macro-Rust-Bibliothek. Sie sind analog zu Compiler-Plug-ins. rust_proc_macro, Seite „Bibliotheksmodule“
rust_testErzeugt eine Rust-Testbinärdatei mit dem Standard-Rust-Test-Harnisch. Seite Module testen
rust_fuzzErzeugt eine Rust-Fuzz-Binärdatei mithilfe der libfuzzer Beispiel für das Modul rust_fuzz
rust_protobufGeneriert eine Quelle und erstellt einen Rust-Wert -Bibliothek, die eine Schnittstelle für einen bestimmten protobuf bereitstellt. Seiten Protobufs-Module und Source Generators
rust_bindgenGeneriert 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 Modulname.

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 Moduls
  • android ist der strengste Lint-Satz, der für den gesamten Android-Plattformcode gilt
  • vendor einen gelockerten Satz von Lints auf den Anbietercode angewendet
  • none, 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 Modulstandort
  • android ist der strengste Lint-Satz, der für den gesamten Android-Plattformcode gilt
  • vendor einen gelockerten Satz von Lints auf den Anbietercode angewendet
  • none, 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 sein 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.