-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trouble accessing from non-top level? #5
Comments
Yeah, this is the same problem as capnproto/capnproto-rust#16. I'm closing that issue in favor of this one. |
My hacky solution to this was to tweak the The 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 While it would be possible to get working completion by fixing this issue in Racer and RLS, the use of |
It seems to work in a submodule as long as you still have |
@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 |
@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 capnproto/capnproto-rust#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 capnproto/capnproto-rust#16
The text was updated successfully, but these errors were encountered: