Система сборки поддерживает создание интерфейсов protobuf с помощью типа rust_protobuf
.
Базовая генерация кода protobuf выполняется с помощью крейта rust-protobuf
. Чтобы просмотреть документацию по этому использованию, посетите страницу проекта GitHub с соответствующими примерами protobuf.
Также поддерживаются protobufs gRPC, генерация которых обеспечивается крейтом grpc-rs
. Чтобы просмотреть документацию по такому использованию, см. документацию на соответствующей странице проекта gRPC на GitHub .
Базовое использование сборки Rust_protobuf
Ниже приведен пример определения модуля protobuf и использования этого модуля в качестве контейнера. Более подробную информацию о важных свойствах и том, как они используются, можно найти в разделе «Определение rust_protobuf
.
Если вам нужно использовать код, сгенерированный protobuf, через макрос include!()
, например, для стороннего кода, см. пример на странице Генераторы исходного кода . (В примере используется rust_bindgen
, но способы включения исходного кода одинаковы для всех генераторов исходного кода.)
Определите модуль Rust_protobuf Android.bp.
Предположим, что в src/protos/my.proto
есть какой-то прототип относительно вашего Android.bp; тогда модуль определяется следующим образом:
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",
}
Библиотека, использующая этот крейт, определяется путем ссылки на нее, как если бы это была любая другая зависимость библиотеки:
rust_binary {
name: "hello_rust_proto",
srcs: ["src/main.rs"],
rustlibs: ["libmy_proto"],
}
Структура крейта модулей Rust_protobuf
Каждый файл protobuf организован как отдельный модуль внутри контейнера, получив имя файла protobuf. Это означает, что все имена базовых файлов прототипа должны быть уникальными. Например, возьмем rust_protobuf
, определенную следующим образом:
rust_protobuf {
name: "libfoo",
crate_name: "foo",
protos: ["a.proto", "b.proto"],
grpc_protos: ["c.proto"],
source_stem: "my_proto_source",
}
Доступ к различным прототипам в этом ящике будет осуществляться следующим образом:
// 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
Примечательные свойства ржавчины_protobuf
Определенные ниже свойства дополняют важные общие свойства , применимые ко всем модулям. Они либо особенно важны для модулей Rust protobuf, либо демонстрируют уникальное поведение, специфичное для типа rust_protobuf
.
стебель, имя, имя_ящика
rust_protobuf
создает варианты библиотеки, поэтому для этих трех свойств существуют те же требования, что и для rust_library
. Подробности смотрите в свойствах rust_library
.
протос
Это список относительных путей к файлам protobuf для создания интерфейса protobuf. Базовые имена файлов должны быть уникальными для protos
и grpc_protos
.
grpc_protos
grpc_protos
состоит из списка относительных путей к файлам protobuf, которые определяют grpcs
для создания интерфейса protobuf. Базовые имена файлов должны быть уникальными для protos
и grpc_protos
.
исходный_ствол
source_stem
— это имя сгенерированного исходного файла , который можно включить. Это обязательное определение поля, даже если вы используете привязки в качестве контейнера, поскольку свойство stem
управляет только именем выходного файла для сгенерированных вариантов библиотеки. В отличие от других генераторов исходного кода, к имени файла добавляется префикс mod_ , что делает окончательное имя файла mod_<stem> . Это предотвращает конфликты имен с сгенерированными источниками из каждого прототипа.
Кроме того, как и в модуле привязок привязки, доступен полный набор свойств библиотеки для управления компиляцией библиотеки, хотя их редко требуется определять или изменять.