attribute-based configuration of `transport` in `tonic-build`
- Dominant language
- Rust
- Stars
- 12.5k
- Forks
- 1.3k
- Avg merge
- 4d 7h
- Merged PRs (30d)
- 24
Description
## Feature Request
Allow the `transport` functionality of `tonic-build` to be attribute-based rather than completely included/omitted.
### Crates
`tonic-build`
### Motivation
I am using tonic in a Rust crate that targets both regular environments and wasm32. The transport feature needs to be disabled for wasm32, and so I end up having to generate 2 completely different sets of files (i.e. run through the builder once with the feature enabled and a "with-transport" dir, and then a second time with "no-transport" dir.)
It works, but, not without some friction.
Alternatively, parsing the output with a regex replacement and feature-gating, which is smoother for consumers but a bit scary to ensure it's doing the right thing consistently.
### Proposal
I'm not familiar with the internals of tonic-build to know if it's possible, but the idea would be to use the `client_attribute` and `server_attribute` functionality, or something like, it to generate the transport stuff with the `cfg` rules there, such that consumer crates can use the same files regardless, i.e. move the determination of "transport" down to the consumer level.
This could, of course, merely be an extension on top of the current functionality (i.e. not having the transport feature won't emit it at all, this would only be an additional configuration on top of the current functionality, and should be fully backwards-compatible)
Contributor guide
Assessment
This issue has not been assessed yet.