You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're using tonic_build to compile both proto and service definitions. However, we'd like to gate the service definitions on a cargo feature (e.g. grpc), so it's possible to use the protos independently of Tonic for use in e.g. WASM environments.
Proposal
Add a new method to tonic_builder::Builder similar to the existing field_attribute and type_attribute methods, but instead: module_attribute.
This would make it possible to add an attribute like #[cfg(feature = "grpc")] to the generated modules to gate usages of Tonic.
Alternatives
We managed to "solve" our immediate problem by munging the output of tonic_build, however it's something of a brittle hack. A first-class feature for this would be much more robust.
The text was updated successfully, but these errors were encountered:
Feature Request
Crates
tonic_build
Motivation
We're using
tonic_build
to compile both proto and service definitions. However, we'd like to gate the service definitions on a cargo feature (e.g.grpc
), so it's possible to use the protos independently of Tonic for use in e.g. WASM environments.Proposal
Add a new method to
tonic_builder::Builder
similar to the existingfield_attribute
andtype_attribute
methods, but instead:module_attribute
.This would make it possible to add an attribute like
#[cfg(feature = "grpc")]
to the generated modules to gate usages of Tonic.Alternatives
We managed to "solve" our immediate problem by munging the output of
tonic_build
, however it's something of a brittle hack. A first-class feature for this would be much more robust.The text was updated successfully, but these errors were encountered: