Protobuf-Module

Das Build-System unterstützt die Generierung von Protobuf-Schnittstellen über den Modultyp rust_protobuf .

Die grundlegende Generierung von Protobuf-Code wird mit der rust-protobuf Kiste durchgeführt. Die Dokumentation zu dieser Verwendung finden Sie auf der GitHub-Projektseite mit den entsprechenden Protobuf -Beispielen .

gRPC-Protobufs werden ebenfalls unterstützt, wobei die Generierung durch die grpc-rs Kiste erfolgt. Die Dokumentation zu dieser Verwendung finden Sie in der Dokumentation auf der entsprechenden gRPC -GitHub-Projektseite .

Grundlegende Verwendung des rust_protobuf-Builds

Im Folgenden finden Sie ein Beispiel für die Definition eines Protobuf-Moduls und die Verwendung dieses Moduls als Crate. Weitere Details zu wichtigen Eigenschaften und deren Verwendung finden Sie im Abschnitt Definieren eines rust_protobuf .

Wenn Sie protobuf-generierten Code über ein include!() Makro verwenden müssen, z. B. für Code von Drittanbietern, finden Sie auf der Seite „Quellgeneratoren“ ein Beispiel. (Das Beispiel verwendet ein rust_bindgen Modul, aber die Mittel zur Quelleneinbindung sind für alle Quellengeneratoren gleich.)

Definieren Sie ein rust_protobuf Android.bp-Modul

Nehmen Sie ein Proto unter src/protos/my.proto relativ zu Ihrem Android.bp an; Das Modul ist dann wie folgt definiert:

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",
}

Eine Bibliothek, die diese Kiste verwendet, wird definiert, indem sie so referenziert wird, als wäre sie eine andere Bibliotheksabhängigkeit:

rust_binary {
    name: "hello_rust_proto",
    srcs: ["src/main.rs"],
    rustlibs: ["libmy_proto"],
}

Kistenstruktur von rust_protobuf-Modulen

Jede Protobuf-Datei ist als eigenes Modul innerhalb der Kiste organisiert und trägt den Namen der Protobuf-Datei. Das bedeutet, dass alle Proto-Basisdateinamen eindeutig sein müssen. Nehmen Sie zum Beispiel ein rust_protobuf , das wie folgt definiert ist:

rust_protobuf {
    name: "libfoo",
    crate_name: "foo",
    protos: ["a.proto", "b.proto"],
    grpc_protos: ["c.proto"],
    source_stem: "my_proto_source",
}

Auf die verschiedenen Protos in dieser Kiste kann wie folgt zugegriffen werden:

// 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

Bemerkenswerte rust_protobuf-Eigenschaften

Die unten definierten Eigenschaften gelten zusätzlich zu den wichtigen allgemeinen Eigenschaften , die für alle Module gelten. Diese sind entweder besonders wichtig für Rust-Protobuf-Module oder weisen ein einzigartiges Verhalten auf, das für den Modultyp rust_protobuf spezifisch ist.

Stamm, Name, Crate_Name

rust_protobuf erzeugt Bibliotheksvarianten, daher gelten für diese drei Eigenschaften die gleichen Anforderungen wie für die rust_library Module. Weitere Informationen finden Sie in den rust_library Eigenschaften.

Protos

Dies ist eine Liste relativer Pfade zu den Protobuf-Dateien zum Generieren der Protobuf-Schnittstelle. Die Basisdateinamen müssen für protos und grpc_protos eindeutig sein.

grpc_protos

Das grpc_protos besteht aus einer Liste relativer Pfade zu den Protobuf-Dateien, die grpcs zum Generieren der Protobuf-Schnittstelle definieren. Die Basisdateinamen müssen für protos und grpc_protos eindeutig sein.

source_stem

source_stem ist der Dateiname der generierten Quelldatei , die eingebunden werden kann. Dies ist eine erforderliche Felddefinition, auch wenn Sie die Bindungen als Crate verwenden, da die stem nur den Ausgabedateinamen für die generierten Bibliotheksvarianten steuert. Im Gegensatz zu anderen Quellgeneratoren wird dem Dateinamen mod_ vorangestellt , wodurch der endgültige Dateiname mod_<stem> entsteht. Dies verhindert Namenskollisionen mit generierten Quellen aus jedem Proto.

Darüber hinaus steht, wie beim bindgen-Bindungsmodul, auch der vollständige Satz an Bibliothekseigenschaften zur Steuerung der Bibliothekskompilierung zur Verfügung, obwohl diese selten definiert oder geändert werden müssen.