Using CodeGeneratorRequest directly

[freopen]

Is there any way to access the CodeGeneratorRequest object from what was generated in the build.rs? What I have in mind is a proc_macro that implements additional traits for generated Reader and Builder structs based on custom annotations in the .capnp file?

If there is no way for that, can I write a simple PR that adds a method to capnpc::CompilerCommand that is similar to file_descriptor_set_path from prost_build to output a serialized CodeGeneratorRequest into the OUT_DIR so I can read it from my proc_macro? Or maybe some different way to access it like returning a CodeGeneratorRequest reader from a separate version of CompilerCommand::run() function?

[dwrensha]

Can you describe more about what your additional traits will do?

capnproto-c++ saves essentially all of the infomation of the CodeGeneratorRequest into the generated source code itself, in order to support the dynamic reflection API. Would something like that help with what you're doing?

[freopen]

I'm trying to make a structured KV database with schema based on Capnp schema. I did something similar with Protobuf already, but Protos are a bit awkward about custom annotations so I wanted to try to do the same with Capnp instead. My idea was to read a proto file descriptor, find annotations that tell us how to deduce a key from a value: https://github.com/freopen/pbdb/blob/main/integration-tests/proto/tests.proto#L8, then extend the type with methods to interact with database: https://github.com/freopen/pbdb/blob/main/src/lib.rs#L21, using proc_macros: https://github.com/freopen/pbdb/blob/main/pbdb-macros/src/lib.rs.

You could make const functions returning metadata about the structure, but I believe my proc_macro crate won't be able to use them as it's going to expand into the same space. Using proc derive macros seems complicated because there are no actual fields to attach the macro annotations to, just a set of functions per field, so it will be awkward to use. Maybe having a big fat macro annotation with all the dependencies attached for every Reader and Builder will do but it seems awkward too. Runtime implementation seem to require going through each field's annotations every time we are extracting key from value, sounds much worse than compile-time variant.

[dwrensha]

Adding a new option to CompilerCommand for saving the CodeGeneratorRequest sounds reasonable to me, if that's going to unblock your progress. Working with the raw CodeGeneratorRequest is going to be rough, though. It would be nice if capnpc exposed a nice API to help with that -- for things like resolving IDs and generics. capnproto-c++ has the Schema class for this purpose: https://github.com/capnproto/capnproto/blob/2ed8664a08e2c92f0af39e213c20b13d15c03346/c%2B%2B/src/capnp/schema.h#L77.