Questa pagina fornisce una visione di alto livello di come è supportata l'origine generata e di come può essere utilizzata nel sistema di compilazione.
Tutti i generatori di sorgenti forniscono funzionalità di sistema di compilazione simili. I tre casi d'uso di generazione di sorgenti supportati dal sistema di build generano associazioni C utilizzando interfacce bindgen, AIDL e protobuf.
Casse dalla fonte generata
Ogni modulo Rust che genera codice sorgente può essere utilizzato come un crate, esattamente come se fosse definito come rust_library . (Ciò significa che può essere definito come una dipendenza nelle proprietà rustlibs , rlibs e dylibs .) Il miglior modello di utilizzo per il codice della piattaforma è utilizzare il sorgente generato come un crate. Anche se include! è supportata per l'origine generata, il suo scopo principale è supportare codice di terze parti che risiede in external/ .
Ci sono casi in cui il codice della piattaforma potrebbe comunque utilizzare l'origine generata tramite la macro include!() , come quando si utilizza un modulo genrule per generare l'origine in modo univoco.
Utilizzare include!() per includere la fonte generata
L'uso del sorgente generato come contenitore è coperto dagli esempi in ciascuna pagina specifica del modulo (rispettivo). Questa sezione mostra come fare riferimento all'origine generata tramite la macro include!() . Tieni presente che questo processo è simile per tutti i generatori di sorgenti.
Prerequisito
Questo esempio si basa sul presupposto che tu abbia definito un modulo rust_bindgen ( libbuzz_bindgen ) e puoi procedere ai passaggi per includere il codice sorgente generato per utilizzare la macro include!() . Se non lo hai fatto, vai a Definizione di un modulo Rust Bindgen , crea libbuzz_bindgen , quindi torna qui.
Tieni presente che le parti del file di build sono applicabili a tutti i generatori di sorgenti.
Passaggi per includere l'origine generata
Crea external/rust/hello_bindgen/Android.bp con i seguenti contenuti:
rust_binary {
name: "hello_bzip_bindgen_include",
srcs: [
// The primary rust source file must come first in this list.
"src/lib.rs",
// The module providing the bindgen bindings is
// included in srcs prepended by ":".
":libbuzz_bindgen",
],
// Dependencies need to be redeclared when generated source is used via srcs.
shared_libs: [
"libbuzz",
],
}
Crea external/rust/hello_bindgen/src/bindings.rs con i seguenti contenuti:
#![allow(clippy::all)]
#![allow(non_upper_case_globals)]
#![allow(non_camel_case_types)]
#![allow(non_snake_case)]
#![allow(unused)]
#![allow(missing_docs)]
// Note that "bzip_bindings.rs" here must match the source_stem property from
// the rust_bindgen module.
include!(concat!(env!("OUT_DIR"), "/bzip_bindings.rs"));
Crea external/rust/hello_bindgen/src/lib.rs con il seguente contenuto:
mod bindings;
fn main() {
let mut x = bindings::foo { x: 2 };
unsafe { bindings::fizz(1, &mut x as *mut bindings::foo) }
}
Perché casse per la fonte generata
A differenza dei compilatori C/C++, rustc accetta solo un singolo file sorgente che rappresenta un punto di ingresso in un binario o in una libreria. Si prevede che l'albero dei sorgenti sia strutturato in modo tale che tutti i file sorgente richiesti possano essere rilevati automaticamente. Ciò significa che il sorgente generato deve essere inserito nell'albero dei sorgenti o fornito tramite una direttiva include nel sorgente:
include!("/path/to/hello.rs");
La comunità Rust dipende dagli script build.rs e dalle ipotesi sull'ambiente di compilazione Cargo per lavorare con questa differenza . Durante la compilazione, il comando cargo imposta una variabile di ambiente OUT_DIR in cui si prevede che gli script build.rs inseriscano il codice sorgente generato. Utilizzare il comando seguente per includere il codice sorgente:
include!(concat!(env!("OUT_DIR"), "/hello.rs"));
Ciò rappresenta una sfida per Soong poiché gli output di ciascun modulo sono posizionati nella propria directory out/ 1 . Non esiste un singolo OUT_DIR in cui le dipendenze restituiscono la fonte generata.
Per il codice della piattaforma, AOSP preferisce comprimere il codice sorgente generato in un contenitore che può essere importato, per diversi motivi:
- Evita la collisione dei nomi dei file di origine generati.
- Riduci il codice boilerplate registrato in tutto l'albero che richiede manutenzione. Qualsiasi boilerplate necessario per compilare il sorgente generato in un crate può essere mantenuto a livello centrale.
- Evita le interazioni 2 implicite tra il codice generato e il crate circostante.
- Riduci la pressione sulla memoria e sul disco collegando dinamicamente le origini generate di uso comune.
Di conseguenza, tutti i tipi di moduli di generazione del sorgente Rust di Android producono codice che può essere compilato e utilizzato come crate . Soong supporta ancora i crate di terze parti senza modifiche se tutte le dipendenze sorgente generate per un modulo vengono copiate in un'unica directory per modulo, simile a Cargo. In questi casi, Soong imposta la variabile d'ambiente OUT_DIR su quella directory durante la compilazione del modulo, in modo che sia possibile trovare il sorgente generato. Tuttavia, per i motivi già descritti, è consigliabile utilizzare questo meccanismo nel codice della piattaforma solo quando è assolutamente necessario.
Ciò non presenta alcun problema per C/C++ e linguaggi simili, poiché il percorso al sorgente generato viene fornito direttamente al compilatore. ↩
Dal
include!funziona mediante inclusione testuale, potrebbe fare riferimento a valori dallo spazio dei nomi che lo racchiude, modificare lo spazio dei nomi o utilizzare costrutti come#![foo]. Queste interazioni implicite possono essere difficili da mantenere. Preferisci sempre le macro quando è veramente necessaria l'interazione con il resto della cassa. ↩
Questa pagina fornisce una visione di alto livello di come è supportata l'origine generata e di come può essere utilizzata nel sistema di compilazione.
Tutti i generatori di sorgenti forniscono funzionalità di sistema di compilazione simili. I tre casi d'uso di generazione di sorgenti supportati dal sistema di build generano associazioni C utilizzando interfacce bindgen, AIDL e protobuf.
Casse dalla fonte generata
Ogni modulo Rust che genera codice sorgente può essere utilizzato come un crate, esattamente come se fosse definito come rust_library . (Ciò significa che può essere definito come una dipendenza nelle proprietà rustlibs , rlibs e dylibs .) Il miglior modello di utilizzo per il codice della piattaforma è utilizzare il sorgente generato come un crate. Anche se include! è supportata per l'origine generata, il suo scopo principale è supportare codice di terze parti che risiede in external/ .
Ci sono casi in cui il codice della piattaforma potrebbe comunque utilizzare l'origine generata tramite la macro include!() , come quando si utilizza un modulo genrule per generare l'origine in modo univoco.
Utilizzare include!() per includere la fonte generata
L'uso del sorgente generato come contenitore è coperto dagli esempi in ciascuna pagina specifica del modulo (rispettivo). Questa sezione mostra come fare riferimento all'origine generata tramite la macro include!() . Tieni presente che questo processo è simile per tutti i generatori di sorgenti.
Prerequisito
Questo esempio si basa sul presupposto che tu abbia definito un modulo rust_bindgen ( libbuzz_bindgen ) e puoi procedere ai passaggi per includere il codice sorgente generato per utilizzare la macro include!() . Se non lo hai fatto, vai a Definizione di un modulo Rust Bindgen , crea libbuzz_bindgen , quindi torna qui.
Tieni presente che le parti del file di build sono applicabili a tutti i generatori di sorgenti.
Passaggi per includere l'origine generata
Crea external/rust/hello_bindgen/Android.bp con i seguenti contenuti:
rust_binary {
name: "hello_bzip_bindgen_include",
srcs: [
// The primary rust source file must come first in this list.
"src/lib.rs",
// The module providing the bindgen bindings is
// included in srcs prepended by ":".
":libbuzz_bindgen",
],
// Dependencies need to be redeclared when generated source is used via srcs.
shared_libs: [
"libbuzz",
],
}
Crea external/rust/hello_bindgen/src/bindings.rs con i seguenti contenuti:
#![allow(clippy::all)]
#![allow(non_upper_case_globals)]
#![allow(non_camel_case_types)]
#![allow(non_snake_case)]
#![allow(unused)]
#![allow(missing_docs)]
// Note that "bzip_bindings.rs" here must match the source_stem property from
// the rust_bindgen module.
include!(concat!(env!("OUT_DIR"), "/bzip_bindings.rs"));
Crea external/rust/hello_bindgen/src/lib.rs con il seguente contenuto:
mod bindings;
fn main() {
let mut x = bindings::foo { x: 2 };
unsafe { bindings::fizz(1, &mut x as *mut bindings::foo) }
}
Perché casse per la fonte generata
A differenza dei compilatori C/C++, rustc accetta solo un singolo file sorgente che rappresenta un punto di ingresso in un binario o in una libreria. Si prevede che l'albero dei sorgenti sia strutturato in modo tale che tutti i file sorgente richiesti possano essere rilevati automaticamente. Ciò significa che il sorgente generato deve essere inserito nell'albero dei sorgenti o fornito tramite una direttiva include nel sorgente:
include!("/path/to/hello.rs");
La comunità Rust dipende dagli script build.rs e dalle ipotesi sull'ambiente di compilazione Cargo per lavorare con questa differenza . Durante la compilazione, il comando cargo imposta una variabile di ambiente OUT_DIR in cui si prevede che gli script build.rs inseriscano il codice sorgente generato. Utilizzare il comando seguente per includere il codice sorgente:
include!(concat!(env!("OUT_DIR"), "/hello.rs"));
Ciò rappresenta una sfida per Soong poiché gli output di ciascun modulo sono posizionati nella propria directory out/ 1 . Non esiste un singolo OUT_DIR in cui le dipendenze restituiscono la fonte generata.
Per il codice della piattaforma, AOSP preferisce comprimere il codice sorgente generato in un contenitore che può essere importato, per diversi motivi:
- Evita la collisione dei nomi dei file di origine generati.
- Riduci il codice boilerplate registrato in tutto l'albero che richiede manutenzione. Qualsiasi boilerplate necessario per compilare il sorgente generato in un crate può essere mantenuto a livello centrale.
- Evita le interazioni 2 implicite tra il codice generato e il crate circostante.
- Riduci la pressione sulla memoria e sul disco collegando dinamicamente le origini generate di uso comune.
Di conseguenza, tutti i tipi di moduli di generazione del sorgente Rust di Android producono codice che può essere compilato e utilizzato come crate . Soong supporta ancora i crate di terze parti senza modifiche se tutte le dipendenze sorgente generate per un modulo vengono copiate in un'unica directory per modulo, simile a Cargo. In questi casi, Soong imposta la variabile d'ambiente OUT_DIR su quella directory durante la compilazione del modulo, in modo che sia possibile trovare il sorgente generato. Tuttavia, per i motivi già descritti, è consigliabile utilizzare questo meccanismo nel codice della piattaforma solo quando è assolutamente necessario.
Ciò non presenta alcun problema per C/C++ e linguaggi simili, poiché il percorso al sorgente generato viene fornito direttamente al compilatore. ↩
Dal
include!funziona mediante inclusione testuale, potrebbe fare riferimento a valori dallo spazio dei nomi che lo racchiude, modificare lo spazio dei nomi o utilizzare costrutti come#![foo]. Queste interazioni implicite possono essere difficili da mantenere. Preferisci sempre le macro quando è veramente necessaria l'interazione con il resto della cassa. ↩
Questa pagina fornisce una visione di alto livello di come è supportata l'origine generata e di come può essere utilizzata nel sistema di compilazione.
Tutti i generatori di sorgenti forniscono funzionalità di sistema di compilazione simili. I tre casi d'uso di generazione di sorgenti supportati dal sistema di build generano associazioni C utilizzando interfacce bindgen, AIDL e protobuf.
Casse dalla fonte generata
Ogni modulo Rust che genera codice sorgente può essere utilizzato come un crate, esattamente come se fosse definito come rust_library . (Ciò significa che può essere definito come una dipendenza nelle proprietà rustlibs , rlibs e dylibs .) Il miglior modello di utilizzo per il codice della piattaforma è utilizzare il sorgente generato come un crate. Anche se include! è supportata per l'origine generata, il suo scopo principale è supportare codice di terze parti che risiede in external/ .
Ci sono casi in cui il codice della piattaforma potrebbe comunque utilizzare l'origine generata tramite la macro include!() , come quando si utilizza un modulo genrule per generare l'origine in modo univoco.
Utilizzare include!() per includere la fonte generata
L'uso del sorgente generato come contenitore è coperto dagli esempi in ciascuna pagina specifica del modulo (rispettivo). Questa sezione mostra come fare riferimento all'origine generata tramite la macro include!() . Tieni presente che questo processo è simile per tutti i generatori di sorgenti.
Prerequisito
Questo esempio si basa sul presupposto che tu abbia definito un modulo rust_bindgen ( libbuzz_bindgen ) e puoi procedere ai passaggi per includere il codice sorgente generato per utilizzare la macro include!() . Se non lo hai fatto, vai a Definizione di un modulo Rust Bindgen , crea libbuzz_bindgen , quindi torna qui.
Tieni presente che le parti del file di build sono applicabili a tutti i generatori di sorgenti.
Passaggi per includere l'origine generata
Crea external/rust/hello_bindgen/Android.bp con i seguenti contenuti:
rust_binary {
name: "hello_bzip_bindgen_include",
srcs: [
// The primary rust source file must come first in this list.
"src/lib.rs",
// The module providing the bindgen bindings is
// included in srcs prepended by ":".
":libbuzz_bindgen",
],
// Dependencies need to be redeclared when generated source is used via srcs.
shared_libs: [
"libbuzz",
],
}
Crea external/rust/hello_bindgen/src/bindings.rs con i seguenti contenuti:
#![allow(clippy::all)]
#![allow(non_upper_case_globals)]
#![allow(non_camel_case_types)]
#![allow(non_snake_case)]
#![allow(unused)]
#![allow(missing_docs)]
// Note that "bzip_bindings.rs" here must match the source_stem property from
// the rust_bindgen module.
include!(concat!(env!("OUT_DIR"), "/bzip_bindings.rs"));
Crea external/rust/hello_bindgen/src/lib.rs con il seguente contenuto:
mod bindings;
fn main() {
let mut x = bindings::foo { x: 2 };
unsafe { bindings::fizz(1, &mut x as *mut bindings::foo) }
}
Perché casse per la fonte generata
A differenza dei compilatori C/C++, rustc accetta solo un singolo file sorgente che rappresenta un punto di ingresso in un binario o in una libreria. Si prevede che l'albero dei sorgenti sia strutturato in modo tale che tutti i file sorgente richiesti possano essere rilevati automaticamente. Ciò significa che il sorgente generato deve essere inserito nell'albero dei sorgenti o fornito tramite una direttiva include nel sorgente:
include!("/path/to/hello.rs");
La comunità Rust dipende dagli script build.rs e dalle ipotesi sull'ambiente di compilazione Cargo per lavorare con questa differenza . Durante la compilazione, il comando cargo imposta una variabile di ambiente OUT_DIR in cui si prevede che gli script build.rs inseriscano il codice sorgente generato. Utilizzare il comando seguente per includere il codice sorgente:
include!(concat!(env!("OUT_DIR"), "/hello.rs"));
Ciò rappresenta una sfida per Soong poiché gli output di ciascun modulo sono posizionati nella propria directory out/ 1 . Non esiste un singolo OUT_DIR in cui le dipendenze restituiscono la fonte generata.
Per il codice della piattaforma, AOSP preferisce comprimere il codice sorgente generato in un contenitore che può essere importato, per diversi motivi:
- Evita la collisione dei nomi dei file di origine generati.
- Riduci il codice boilerplate registrato in tutto l'albero che richiede manutenzione. Qualsiasi boilerplate necessario per compilare il sorgente generato in un crate può essere mantenuto a livello centrale.
- Evita le interazioni 2 implicite tra il codice generato e il crate circostante.
- Riduci la pressione sulla memoria e sul disco collegando dinamicamente le origini generate di uso comune.
Di conseguenza, tutti i tipi di moduli di generazione del sorgente Rust di Android producono codice che può essere compilato e utilizzato come crate . Soong supporta ancora i crate di terze parti senza modifiche se tutte le dipendenze sorgente generate per un modulo vengono copiate in un'unica directory per modulo, simile a Cargo. In questi casi, Soong imposta la variabile d'ambiente OUT_DIR su quella directory durante la compilazione del modulo, in modo che sia possibile trovare il sorgente generato. Tuttavia, per i motivi già descritti, è consigliabile utilizzare questo meccanismo nel codice della piattaforma solo quando è assolutamente necessario.
Ciò non presenta alcun problema per C/C++ e linguaggi simili, poiché il percorso al sorgente generato viene fornito direttamente al compilatore. ↩
Dal
include!funziona mediante inclusione testuale, potrebbe fare riferimento a valori dallo spazio dei nomi che lo racchiude, modificare lo spazio dei nomi o utilizzare costrutti come#![foo]. Queste interazioni implicite possono essere difficili da mantenere. Preferisci sempre le macro quando è veramente necessaria l'interazione con il resto della cassa. ↩