As I recall, I used prost because at the time it offered me a way to customize derived traits for the generated types (I needed the serde traits), while the other protobuf crate I looked at did not. That might not be the case now.
CARGO_MANIFEST_DIR is the directory where Cargo.toml lives, so $CARGO_MANIFEST_DIR/src is the project's src directory.
In my case, the definitions were in another repository, and might not always be available if that repo had not been checked out in the right place on the machine doing the build, but I still wanted to be able to build in that case.
Thus, I do run the generator as a build script, but I also commit the output to source control, so rustdoc ought to see it. There's some logic in the build script (that I didn't post) that only runs the protobuf generator if the module is older than the definitions. If I need to force it to regenerate, I can always locally delete the generated module and build, and then commit any differences.
As I recall, I used
prostbecause at the time it offered me a way to customize derived traits for the generated types (I needed theserdetraits), while the other protobuf crate I looked at did not. That might not be the case now.CARGO_MANIFEST_DIRis the directory whereCargo.tomllives, so$CARGO_MANIFEST_DIR/srcis the project'ssrcdirectory.In my case, the definitions were in another repository, and might not always be available if that repo had not been checked out in the right place on the machine doing the build, but I still wanted to be able to build in that case.
Thus, I do run the generator as a build script, but I also commit the output to source control, so
rustdocought to see it. There's some logic in the build script (that I didn't post) that only runs the protobuf generator if the module is older than the definitions. If I need to force it to regenerate, I can always locally delete the generated module and build, and then commit any differences.Ok, that explains a lot, thanks for clarifying. Sounds like a sensible approach.