Come principio generale, le definizioni dei moduli di rust_*
rispettano strettamente
Utilizzo e aspettative di cc_*
. Di seguito è riportato un esempio di modulo
Definizione di 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 dei 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
Tipo | Definizione | Per ulteriori informazioni |
---|---|---|
rust_binary | Un file binario Rust. | Moduli binari pagina |
rust_library | Genera una libreria Rust e fornisce rlib e
dylib varianti. |
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 dei moduli della libreria |
rust_proc_macro | Genera una raccolta Rust di proc-macro .
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 metodo imbracatura di prova Rust standard. | Pagina Moduli di test |
rust_fuzz | Produce un file binario fuzz Rust sfruttando
libfuzzer . |
Esempio di modulo rust_fuzz |
rust_protobuf | Genera il codice sorgente e produce una Rust che fornisce un'interfaccia per un particolare protobuf. | Pagine Moduli Protobufs e Generatori di codice |
rust_bindgen | Genera il codice sorgente e produce un Libreria Rust contenente associazioni Rust alle librerie C. | Moduli di associazioni di binding e Generatori di codice |
Importanti proprietà comuni
Queste proprietà sono comuni a tutti i dispositivi Android Rust Moduli. 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 file di output (ad eccezione
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 forniscono un valore per la proprietà stem
, il nome file di output adotta il valore
nome del modulo per impostazione predefinita.
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 l'output
il file è 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.
nome_cassa
crate_name
imposta i metadati del nome della cassa tramite rustc
--crate_name
flag. 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
Moduli della libreria
.
peli
Il linter color ruggine viene eseguito per impostazione predefinita per tutti i tipi di moduli, ad eccezione dei generatori di codice sorgente. Alcuni set di lint sono definite e utilizzate per convalidare le origini dei moduli. Valori possibili per il lint sono i seguenti:
default
l'insieme predefinito di linee, a seconda della posizione del moduloandroid
il set di lint più rigoroso che si applica a tutto il codice della piattaforma Androidvendor
un insieme informale di litte applicato al codice del fornitorenone
per 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:
default
insieme predefinito di suggerimenti in base alla posizione del moduloandroid
il set di lint più rigoroso che si applica a tutto il codice della piattaforma Androidvendor
un insieme informale di litte applicato al codice del fornitorenone
per ignorare tutti gli avvisi e gli errori lint
edizione
edition
definisce la versione Rust da utilizzare per
la compilazione di questo codice. Questa operazione è simile a quella delle versioni standard per C e C++. Valori validi
sono 2015
e 2018
(valore predefinito).
flag
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
sorgente. Questi vengono superati dalla bandiera rustc -C linker-args
. 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,
pertanto, in molti casi, si tratta dell'intero set di caratteristiche richieste
moduli. 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 particolare
in uno dei seguenti casi:
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.
Valori aggiuntivi sono disponibili nel
Riferimento ai moduli Soong.
supportato_da_host
Per i moduli dispositivo, il parametro host_supported
indica se il modulo
dovrebbe anche fornire una variante host.
Definisci le dipendenze della libreria
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. Usa come
il metodo preferito per la dichiarazione delle dipendenze, in quanto consente al sistema di build
seleziona il collegamento che preferisci. (Vedi Quando si esegue il collegamento a librerie Rust di seguito) |
rlibs |
Elenco di rust_library moduli che devono essere collegati in modo statico
come rlibs . (Da usare con cautela; vedi
Quando esegui il collegamento a librerie Rust, di seguito. |
shared_libs |
Elenco di cc_library moduli che devono essere dinamici
collegate come raccolte condivise. |
static_libs |
Elenco di cc_library moduli che devono essere statici
collegate 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 build non supportate e con supporto limitato
Presto Rust offre supporto limitato per vendor
e
vendor_ramdisk
immagini e istantanee. 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 recupero non sono supportate.
Build incrementali
Gli sviluppatori possono attivare la compilazione incrementale
Origine Rust impostando SOONG_RUSTC_INCREMENTAL
variabile di ambiente in true
.
Attenzione: non è garantito che producano programmi binari identici a questi generate dai buildbot. Gli indirizzi delle funzioni o dei dati contenuti che possono essere diversi. assicurare che gli artefatti generati siano al 100% identici a quelli creati dall'infrastruttura EngProd, lascia questo valore non impostato.