Le système de construction 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 caisse rust-protobuf . Pour afficher la documentation sur cette utilisation, consultez la page du projet GitHub avec les exemples de protobuf correspondants.
Les protobufs gRPC sont également pris en charge, avec une génération assurée par la caisse grpc-rs . Pour afficher la documentation sur cette utilisation, consultez la documentation sur la page du projet gRPC GitHub correspondant.
Utilisation de base de la construction rust_protobuf
Ce qui suit fournit un exemple de définition d'un module protobuf et d'utilisation de ce module comme caisse. Plus de détails sur les propriétés importantes et la façon dont elles sont utilisées se trouvent dans la section Définition d'un rust_protobuf .
Si vous devez utiliser du code généré par protobuf via une macro include!() , comme pour du code tiers, consultez la page Générateurs de sources pour un exemple. (L'exemple utilise un module rust_bindgen , mais le moyen d'inclusion de source est le même pour tous les générateurs de source.)
Définir un module rust_protobuf Android.bp
Supposons un proto dans src/protos/my.proto par rapport à votre Android.bp ; le module est alors 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 y faisant référence comme s'il s'agissait d'une autre dépendance de bibliothèque :
rust_binary {
name: "hello_rust_proto",
srcs: ["src/main.rs"],
rustlibs: ["libmy_proto"],
}
Structure de caisse des modules rust_protobuf
Chaque fichier protobuf est organisé comme son propre module au sein de la caisse, prenant le nom du fichier protobuf. Cela signifie que tous les noms de fichiers de base de proto doivent être uniques. Par exemple, prenons 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 notables de rust_protobuf
Les propriétés définies ci-dessous s'ajoutent aux propriétés communes importantes qui s'appliquent à tous les modules. Ceux-ci sont soit particulièrement importants pour les modules Rust protobuf, soit présentent un comportement unique spécifique au type de module rust_protobuf .
tige, nom, nom_crate
rust_protobuf produit des variantes de bibliothèque, donc les mêmes exigences existent pour ces trois propriétés que pour les modules rust_library . Voir les propriétés rust_library pour plus de détails.
protos
Il s'agit d'une liste de chemins relatifs vers les fichiers protobuf pour générer l'interface protobuf. Les noms de fichiers de base doivent être uniques entre protos et grpc_protos .
grpc_protos
Le grpc_protos consiste en une liste de chemins relatifs vers les fichiers protobuf qui définissent grpcs pour générer l'interface protobuf. Les noms de fichiers de base doivent être uniques entre protos et grpc_protos .
source_stem
source_stem est le nom de fichier du fichier source généré qui peut être inclus. Il s'agit d'une définition de champ obligatoire, même si vous utilisez les liaisons comme caisse, puisque la propriété stem contrôle uniquement le nom du fichier de sortie pour les variantes de bibliothèque générées. Contrairement aux autres générateurs de sources, le nom de fichier est préfixé par mod_ , ce qui donne le nom de fichier final mod_<stem> . Cela évite les collisions de noms avec les sources générées à partir de chaque proto.
De plus, comme le module de liaisons bindgen, 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 les définir ou de les modifier.