Come principio generale, le definizioni dei moduli rust_* si attengono strettamente all'utilizzo e alle aspettative di cc_*. Di seguito è riportato un esempio di definizione di modulo per un file binario Rust:
rust_binary {
name: "hello_rust",
crate_name: "hello_rust",
srcs: ["src/hello_rust.rs"],
host_supported: true,
}
Questa pagina illustra le proprietà più comuni per i moduli rust_*. Per
ulteriori informazioni su tipi di moduli specifici e definizioni di moduli di esempio.
vedi
Moduli binari,
Moduli libreria,
o
Moduli di test.
Tipi di moduli di base
| Digitazione | Definizione | Per ulteriori informazioni |
|---|---|---|
rust_binary | Un file binario Rust. | Moduli binari pagina |
rust_library | Produce una libreria Rust e fornisce sia le varianti rlib sia quelle dylib. |
rust_library,
alla pagina Moduli libreria. |
rust_ffi | Genera una libreria C Rust utilizzabile in Cc e fornisce varianti statiche e condivise. | rust_ffi,
pagina Moduli della raccolta |
rust_proc_macro | Produce una libreria proc-macro Rust.
Sono analoghi ai plug-in del compilatore. |
rust_proc_macro,
Pagina dei moduli delle librerie |
rust_test | Produce un file binario di test Rust che utilizza il test harness Rust standard. | Pagina Testa i moduli |
rust_fuzz | Produce un file binario fuzz Rust sfruttando
libfuzzer. |
Esempio di modulo rust_fuzz |
rust_protobuf | Genera il codice sorgente e produce una libreria Rust che fornisce un'interfaccia per un determinato protobuf. | Pagine Moduli Protobuf e Generatori di codice |
rust_bindgen | Genera il codice sorgente e produce un Libreria Rust contenente associazioni Rust alle librerie C. | Moduli di associazioni Bindgen e pagine Generatori di codice sorgente |
Importanti proprietà comuni
Queste proprietà sono comuni a tutti i moduli Rust per Android. Qualsiasi proprietà (unica) aggiuntiva associata a un singolo I moduli Rust sono elencati nella relativa pagina.
nome
name è il nome del modulo. Come gli altri moduli Qwiklabs, deve essere univoco
nella maggior parte dei tipi di moduli Android.bp. Per impostazione predefinita, viene utilizzato name come output
nome file. Se il nome file di output deve essere diverso dal nome del modulo, utilizza il metodo
stem per definirla.
gambo
stem (facoltativo) fornisce il controllo diretto sul nome del file di output (esclusa
l'estensione del file e altri suffissi). Ad esempio, un rust_library_rlib
libreria con valore stem libfoo, produce un file libfoo.rlib. Se
non fornisci un valore per la proprietà stem, il nome del file di output adotta per impostazione predefinita il
nome del modulo.
Utilizza la funzione stem quando non puoi impostare il nome del modulo sull'output desiderato
nome file. Ad esempio, il valore rust_library per la cassa log è denominato
liblog_rust,
perché liblog cc_library
esiste già. In questo caso, l'utilizzo della proprietà stem garantisce che il file di output sia denominato liblog.* anziché liblog_rust.*.
S
srcs contiene un singolo file di origine che rappresenta il punto di ingresso della
(di solito main.rs o lib.rs). rustc gestisce la risoluzione
il rilevamento di tutti gli altri file sorgente necessari per la compilazione
enumerato nel file deps che viene generato.
Se possibile, evita questo utilizzo per il codice della piattaforma. vedi Generatori di codice sorgente per ulteriori informazioni.
crate_name
crate_name imposta i metadati del nome della cassetta tramite il flag rustc --crate_name. Per i moduli che producono librerie, questo deve corrispondere al
nome della cassa usato nell'origine. Ad esempio, se viene fatto riferimento al modulo libfoo_bar
nel codice sorgente come extern crate foo_bar, deve essere
crate_name: "foo_bar".
Questa proprietà è comune a tutti i moduli rust_*, ma è obbligatoria per i moduli
che producono librerie Rust (ad esempio rust_library
rust_ffi, rust_bindgen, rust_protobuf e rust_proc_macro). Questi
i moduli applicano requisiti rustc alla relazione tra crate_name
e il nome file di output. Per ulteriori informazioni, consulta la sezione Moduli della libreria.
peli
Il linting di rustc viene eseguito per impostazione predefinita per tutti i tipi di moduli, ad eccezione dei generatori di codice sorgente. Alcuni set di lint vengono definiti e utilizzati per convalidare il codice sorgente del modulo. Valori possibili per il lint sono i seguenti:
defaultl'insieme predefinito di linee, a seconda della posizione del moduloandroidil set di lint più rigoroso che si applica a tutto il codice della piattaforma Androidvendorun insieme di lint meno rigorosi applicati al codice del fornitorenoneper ignorare tutti gli avvisi e gli errori lint
clippy_lints
Anche il clippy linter eseguito per impostazione predefinita per tutti i tipi di moduli, ad eccezione dei generatori di codice sorgente. Alcune serie di peculiari utilizzate per convalidare le origini dei moduli. Ecco alcuni possibili valori:
defaultinsieme predefinito di suggerimenti in base alla posizione del moduloandroidil set di lint più rigoroso che si applica a tutto il codice della piattaforma Androidvendorun insieme di lint meno rigorosi applicati al codice del fornitorenoneper ignorare tutti gli avvisi e gli errori lint
edizione
edition definisce la versione Rust da utilizzare per
la compilazione di questo codice. È simile alle versioni std per C e C++. I valori validi sono 2015 e 2018 (predefinito).
flags
flags contiene un elenco di stringhe di flag da passare a rustc durante la compilazione.
ld_flag
ld-flags contiene un elenco di stringhe di flag da passare al linker durante la compilazione del codice sorgente. Questi vengono passati dal flag -C linker-args rustc. clang è utilizzato come
il front-end del linker, richiamando lld per il collegamento effettivo.
funzioni
features è un elenco di stringhe di funzionalità che devono essere abilitate durante la compilazione.
Questo viene passato a Rustc da --cfg 'feature="foo"'. La maggior parte delle funzionalità è additiva, quindi in molti casi è costituito dall'insieme completo di funzionalità richiesto da tutti i moduli dipendenti. Tuttavia, nei casi in cui le funzionalità si escludono l'una dall'altra,
definire moduli aggiuntivi in tutti i file di build che forniscono caratteristiche in conflitto.
cfgs
cfgs contiene un elenco di stringhe di flag cfg da abilitare durante la compilazione.
Questo viene trasmesso a rustc da --cfg foo e --cfg "fizz=buzz".
Il sistema di compilazione imposta automaticamente determinati flag cfg in determinate situazioni, elencate di seguito:
I moduli creati come dylib avranno il set cfg
android_dylib.Per i moduli che utilizzerebbero il VNDK sarà impostato il valore cfg
android_vndk. Questo è simile a__ANDROID_VNDK__per C++.
strip
strip consente di stabilire se e come rimuovere la rimozione del file di output (se applicabile).
Se non viene configurato, i moduli dispositivo eliminano per impostazione predefinita tutte le informazioni tranne quelle mini di debug.
Per impostazione predefinita, i moduli host non eliminano alcun simbolo. I valori validi includono none
per disattivare la rimozione e all per rimuovere tutti i dati, incluse le informazioni di debug mini.
Ulteriori valori sono disponibili nel
riferimento ai moduli Soong.
supportato_da_host
Per i moduli del dispositivo, il parametro host_supported indica se il modulo deve fornire anche una variante host.
Definisci le dipendenze delle librerie
I moduli Rust possono dipendere sia da Cc Librerie Rust tramite le seguenti proprietà:
| Nome proprietà | Descrizione |
|---|---|
rustlibs |
Elenco di rust_library moduli che sono anche dipendenze. Utilizzalo come metodo preferito per dichiarare le dipendenze, in quanto consente al sistema di compilazione di selezionare il collegamento preferito. (Vedi Quando si esegue il collegamento a librerie Rust di seguito) |
rlibs |
Elenco dei moduli rust_library che devono essere collegati in modo statico come rlibs. (da usare con cautela; consulta
Quando esegui il collegamento alle librerie Rust di seguito.) |
shared_libs |
Elenco dei moduli cc_library che devono essere collegati dinamicamente come librerie condivise. |
static_libs |
Elenco dei moduli cc_library che devono essere collegati staticamente come librerie statiche. |
whole_static_libs |
Elenco di cc_library moduli che dovrebbero essere statici
collegate come librerie statiche e incluse nella libreria risultante. Per
rust_ffi_static varianti, whole_static_libraries sarà incluso nel
risultante dall'archivio statico delle librerie. Per rust_library_rlib varianti,
whole_static_libraries librerie verranno incluse nel file rlib risultante
libreria.
|
Durante il collegamento con le librerie Rust, come
best practice, per farlo utilizzando la proprietà rustlibs anziché rlibs o
dylibs, a meno che tu non abbia un motivo specifico per farlo. Questo permette di creare
per selezionare il collegamento corretto in base a ciò che richiede il modulo principale,
e riduce la probabilità che un albero delle dipendenze contenga sia rlib che
dylib versioni di una libreria (che causeranno un errore nella compilazione).
Funzionalità di compilazione non supportate e con supporto limitato
Rust di Soong offre un supporto limitato per le immagini e gli snapshot vendor e
vendor_ramdisk. Tuttavia, staticlibs, cdylibs,
rlibs e binaries sono supportati. Per i target di creazione delle immagini del fornitore,
La proprietà cfg android_vndk è impostata. Puoi usarlo nel codice se ci sono
le differenze tra il target di sistema e quello del fornitore. rust_proc_macros non sono
acquisiti come parte degli snapshot dei fornitori; se dipendono da te, assicurati di
e controllare le versioni in modo appropriato.
Le immagini del prodotto, VNDK e di ripristino non sono supportate.
Build incrementali
Gli sviluppatori possono attivare la compilazione incrementale del codice sorgente di Rust impostando la variabile di ambiente SOONG_RUSTC_INCREMENTAL su true.
Avviso: non è garantito che vengano prodotti binari identici a quelli generati da BuildBot. Gli indirizzi delle funzioni o dei dati contenuti che possono essere diversi. Per assicurarti che gli elementi generati siano uguali al 100% a quelli creati dall'infrastruttura EngProd, lascia questo valore non impostato.