Il sistema di compilazione supporta la generazione di interfacce protobuf tramite il tipo di modulo rust_protobuf .
La generazione del codice protobuf di base viene eseguita con il crate rust-protobuf . Per visualizzare la documentazione su questo utilizzo, vedere la pagina del progetto GitHub con i corrispondenti esempi di protobuf.
Sono supportati anche i protobuf gRPC, con la generazione fornita dal crate grpc-rs . Per visualizzare la documentazione su questo utilizzo, vedere la documentazione nella pagina del progetto gRPC GitHub corrispondente.
Utilizzo di base della build di ruggine_protobuf
Quanto segue fornisce un esempio di definizione di un modulo protobuf e utilizzo di quel modulo come crate. Maggiori dettagli sulle proprietà importanti e su come vengono utilizzate si trovano nella sezione Definizione di un rust_protobuf .
Se è necessario utilizzare il codice generato da protobuf tramite una macro include!() , come per codice di terze parti, vedere la pagina Generatori di sorgenti per un esempio. (L'esempio utilizza un modulo rust_bindgen , ma il mezzo di inclusione del codice sorgente è lo stesso per tutti i generatori di codice sorgente.)
Definire un modulo Rust_protobuf Android.bp
Assumi qualche proto su src/protos/my.proto relativo al tuo Android.bp; il modulo è quindi definito come segue:
rust_protobuf {
name: "libmy_proto",
// Crate name that's used to generate the rust_library variants.
crate_name: "my_proto",
// Relative paths to the protobuf source files
protos: ["src/protos/my.proto"],
// If protobufs define gRPCs, then they should go in grpc_protos
// instead.
// grpc_protos: ["src/protos/my.proto"],
// 'source_stem' controls the output filename.
// This is the filename that's used in an include! macro.
source_stem: "my_proto_source",
}
Una libreria che utilizza questo crate viene definita facendovi riferimento come se fosse qualsiasi altra dipendenza della libreria:
rust_binary {
name: "hello_rust_proto",
srcs: ["src/main.rs"],
rustlibs: ["libmy_proto"],
}
Struttura a cassa dei moduli ruggine_protobuf
Ogni file protobuf è organizzato come un proprio modulo all'interno del crate, prendendo il nome del file protobuf. Ciò significa che tutti i nomi dei file base del prototipo devono essere univoci. Ad esempio, prendi un rust_protobuf definito come segue:
rust_protobuf {
name: "libfoo",
crate_name: "foo",
protos: ["a.proto", "b.proto"],
grpc_protos: ["c.proto"],
source_stem: "my_proto_source",
}
È possibile accedere ai diversi prototipi all'interno di questa cassa come segue:
// use <crate_name>::<proto_filename>
use foo::a; // protobuf interface defined in a.proto
use foo::b; // protobuf interface defined in b.proto
use foo::c; // protobuf interface defined in c.proto
use foo::c_grpc; // grpc interface defined in c.proto
Notevoli proprietà ruggine_protobuf
Le proprietà definite di seguito sono in aggiunta alle proprietà comuni importanti che si applicano a tutti i moduli. Questi sono particolarmente importanti per i moduli Rust protobuf o mostrano un comportamento unico specifico per il tipo di modulo rust_protobuf .
radice, nome, nome_cassa
rust_protobuf produce varianti della libreria, quindi per queste tre proprietà esistono gli stessi requisiti che esistono per i moduli rust_library . Vedi le proprietà rust_library per i dettagli.
prototipi
Questo è un elenco di percorsi relativi ai file protobuf per generare l'interfaccia protobuf. I nomi dei file di base devono essere univoci tra protos e grpc_protos .
grpc_protos
grpc_protos consiste in un elenco di percorsi relativi ai file protobuf che definiscono grpcs per generare l'interfaccia protobuf. I nomi dei file di base devono essere univoci tra protos e grpc_protos .
radice_origine
source_stem è il nome del file sorgente generato che può essere incluso. Questa è una definizione di campo obbligatoria, anche se stai utilizzando i collegamenti come una cassa, poiché la proprietà stem controlla solo il nome del file di output per le varianti della libreria generate. A differenza di altri generatori di sorgenti, il nome file viene preceduto da mod_ , creando il nome file finale mod_<stem> . Ciò impedisce collisioni di nomi con le fonti generate da ciascun prototipo.
Inoltre, come il modulo bindgen bindgen, è disponibile anche l'insieme completo di proprietà della libreria per controllare la compilazione della libreria, sebbene queste raramente debbano essere definite o modificate.