Le système de compilation prend en charge la génération d'interfaces protobuf via le type de module rust_protobuf.
La génération de code protobuf de base est effectuée avec la crate rust-protobuf.
Pour consulter la documentation sur cette utilisation, consultez la page du projet GitHub avec des exemples de tampons de protocole correspondants.
Les protobufs gRPC sont également compatibles, avec une génération fournie par le crate grpc-rs.
Pour en savoir plus sur cette utilisation, consultez la documentation sur la page du projet GitHub gRPC correspondante.
Utilisation de base de la compilation rust_protobuf
L'exemple suivant montre comment définir un module protobuf et l'utiliser comme crate. Pour en savoir plus sur les propriétés importantes et leur utilisation, consultez la section Définir un rust_protobuf.
Si vous devez utiliser du code généré par protobuf via une macro include!(), par exemple pour du code tiers, consultez la page Générateurs de code source pour obtenir un exemple. (L'exemple utilise un module rust_bindgen, mais le moyen d'inclusion des sources est le même pour tous les générateurs de sources.)
Définir un module Android.bp rust_protobuf
Supposons qu'un fichier proto sur src/protos/my.proto soit lié à votre fichier Android.bp. Le module est ensuite défini comme suit:
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",
}
Une bibliothèque qui utilise ce crate est définie en le référençant comme s'il s'agissait de n'importe quelle autre dépendance de bibliothèque:
rust_binary {
name: "hello_rust_proto",
srcs: ["src/main.rs"],
rustlibs: ["libmy_proto"],
}
Structure de crate des modules rust_protobuf
Chaque fichier protobuf est organisé en tant que module distinct dans le crate, et prend le nom du fichier protobuf. Cela signifie que tous les noms de fichiers de base proto doivent être uniques. Prenons l'exemple d'un rust_protobuf défini comme suit:
rust_protobuf {
name: "libfoo",
crate_name: "foo",
protos: ["a.proto", "b.proto"],
grpc_protos: ["c.proto"],
source_stem: "my_proto_source",
}
Les différents protos de cette caisse seraient accessibles comme suit:
// 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
Propriétés rust_protobuf notables
Les propriétés définies ci-dessous s'ajoutent aux propriétés communes importantes qui s'appliquent à tous les modules. Ils sont particulièrement importants pour les modules protobuf Rust ou présentent un comportement unique propre au type de module rust_protobuf.
stem, name, crate_name
rust_protobuf produit des variantes de bibliothèque. Les mêmes exigences s'appliquent donc à ces trois propriétés qu'aux modules rust_library. Pour en savoir plus, consultez les propriétés rust_library.
protos
Il s'agit d'une liste de chemins d'accès relatifs aux fichiers protobuf permettant de générer l'interface protobuf. Les noms de fichiers de base doivent être uniques pour protos et grpc_protos.
grpc_protos
grpc_protos se compose d'une liste de chemins d'accès relatifs aux fichiers protobuf qui définissent grpcs pour générer l'interface protobuf. Les noms de fichiers de base doivent être uniques dans protos et grpc_protos.
tige_source
source_stem est le nom du fichier source généré pouvant être inclus.
Il s'agit d'une définition de champ obligatoire, même si vous utilisez les liaisons en tant que crate, car la propriété stem ne contrôle que le nom de fichier de sortie des variantes de bibliothèque générées. Contrairement aux autres générateurs de sources, le nom de fichier est précédé de mod_, ce qui donne le nom de fichier final mod_<racine>. Cela évite les conflits de noms avec les sources générées à partir de chaque proto.
De plus, comme le module de liaisons "bindinggen", l'ensemble complet des propriétés de la bibliothèque est également disponible pour contrôler la compilation de la bibliothèque, bien qu'il soit rarement nécessaire de définir ou de modifier ces propriétés.