Moduli Android Rust

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

TipoDefinizionePer ulteriori informazioni
rust_binaryUn file binario Rust. Moduli binari pagina
rust_libraryGenera una libreria Rust e fornisce rlib e dylib varianti. rust_library, alla pagina Moduli libreria.
rust_ffiGenera una libreria C Rust utilizzabile in Cc e fornisce varianti statiche e condivise. rust_ffi, Pagina dei moduli della libreria
rust_proc_macroGenera una raccolta Rust di proc-macro. Sono analoghi ai plug-in del compilatore. rust_proc_macro, Pagina dei moduli delle librerie
rust_testProduce un file binario di test Rust che utilizza il metodo imbracatura di prova Rust standard. Pagina Moduli di test
rust_fuzzProduce un file binario fuzz Rust sfruttando libfuzzer. Esempio di modulo rust_fuzz
rust_protobufGenera il codice sorgente e produce una Rust che fornisce un'interfaccia per un particolare protobuf. Pagine Moduli Protobufs e Generatori di codice
rust_bindgenGenera 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 modulo
  • android il set di lint più rigoroso che si applica a tutto il codice della piattaforma Android
  • vendor un insieme informale di litte applicato al codice del fornitore
  • none 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 modulo
  • android il set di lint più rigoroso che si applica a tutto il codice della piattaforma Android
  • vendor un insieme informale di litte applicato al codice del fornitore
  • none per ignorare tutti gli avvisi e gli errori lint
di Gemini Advanced.

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.