Closed Hoverbear closed 6 years ago
Yeah, this is the same problem as https://github.com/dwrensha/capnproto-rust/issues/16. I'm closing that issue in favor of this one.
My hacky solution to this was to tweak the root_name
and root_mod
variables in codegen.rs
like so:
The {0}
in the format string was just because I was experimenting with it and never changed it back to normal.
Then my crate could be organized like:
pub mod my_protocol {
pub mod protocol {
include!(concat!(env!("OUT_DIR"), "/protocols/my_protocol_capnp.rs"));
}
}
...including having them in different files, of course.
Anyway, would it be preferable to simply pass some prefix and postfix strings to the codegen to get the desired module structure, instead of just placing everything in the crate root? If it's done in the build script, we have the full filepath anyway so some more complex things could be done on a per-crate basis.
Or since it's done in the build stage and formatting performance doesn't matter too much for codegen, having a dynamic format string using Handlebars or something would be nifty.
I think the right way to do this would be to define some annotations, as I've suggested here, and read them during codegen.
Huh. That would be pretty nifty. Although having higher level options for use in the build script would also be nice if all the capnp generated modules would have similar paths like with what I did.
I've encountered this issue when trying to avoid using any include!
, as it doesn't play well with RLS/Racer (see this issue, which conveniently references Cap'n'proto as the use case: https://github.com/racer-rust/racer/issues/191).
While it would be possible to get working completion by fixing this issue in Racer and RLS, the use of include!
is explicitly discouraged in its documentation, so I think it would be better to change that behavior here rather than there.
It seems to work in a submodule as long as you still have extern crate capnp;
in your main.rs
.
@eberkund Does your example have any fields that reference structs in the same schema. E.g.
struct Foo {}
struct Bar {
foo @0 : Foo;
}
I would expect this to fail if included in a submodule, because the generated references to Foo
will be absolute paths like ::example_capnp::foo::Reader
.
@dwrensha Oh yea, you are correct. It is a very simple schema without any types depending on one another like you described.
Closing again in favor of https://github.com/capnproto/capnproto-rust/issues/16, as capnpc-rust has been moved back to that repo.
Was playing with this and had the following file structure:
Where
person_capnp.rs
is generated viacapnp compile -o rust src/schema/*.capnp
.I was hoping to include a
schema/mod.rs
which re-exported theperson
inperson_capnp.rs
.schema/mod.rs
:main.rs
:Results in this error:
Fixing
Removing
schema/mod.rs
and makingmain.rs
:Seems to resolve the issue.
This seems to be related to https://github.com/dwrensha/capnproto-rust/issues/16