ernoc
commented
3 months ago Motivations for moving the building of crypto.proto and not have each crate build protos using prost in its own build.rs script and include the resulting output:
- It's not google3 friendly. No build.rs scripts there so the fewer we have / the less work they do, the better. The oak_proto_rust package was initially created to facilitate google3 import.
- In the future we might not use prost, having a single place to change that would be ideal.
- I don't want to keep adding more cargo_build_script bazel targets around the codebase, each calling an opaque build.rs, which could do anything.
- It's also quite confusing to have different crates build the same proto, so you can import the same proto message with different fully qualified names. For a human reader of the code, it adds levels of indirection to figure out what structure is being pulled and what the dependency graph really looks like (code uses proto).
- It's confusing to use a symbol from an indirect dependency. E.g. A using proto from B which imported it and re-exported from C, which built it using build.rs and gave it some module name.
- Not ideal to depend on an entire crate with potentially lots of logic when only the proto structures are needed. Even if the compiler will optimize away all unused parts, cargo will pull the entire dependency tree, and using more parts can easily sneak in without changing any manifest file, and without being able to control package visibility.
- In a few cases a proto file has a clear relationship of "belonging" to a specific crate (e.g. crypto), but this relationship may change and a proto may belong as much to one crate (e.g. a server) and another (e.g. a client).
tiziano88
Also move building of crypto microrcp protos into oak_proto_rust crate.
Change-Id: I3d684aa6c8d1bc104a4551d655438bc52c407a83