Open johnpmayer opened 5 years ago
Hey! Sorry for the delayed response to this - my GitHub notifications are all kinds of messed up 😕
@samsnyder did a little experiment integrating Specs and this project. You can see the branch here https://github.com/jamiebrynes7/spatialos-sdk-rs/tree/feature/specs-integration although I'm really not sure what the state of it is!
I personally don't know enough about Specs to offer a useful opinion about your planned integration, but I'd love to hear more about it 😄
Plugins are a neat idea. I wonder if we could use WASM to dynamically load and execute the plugins. Instead of having a flag --plugin
, it could be part of the Spatial.toml
specification:
[codegen]
schema_paths = ["./schema"]
plugins = [ "<url>/<filepath>" ]
When you say using a build.rs
file, do you mean the crate where my code generation output goes would have a build.rs that looks something like:
fn main() {
let code_generator = SpatialCodegen::new()
.schema_path("../schema")
.plugin(SpatialSpecsCodegen::new());
let generated_code = code_generator.generate().expect("Failed to generate");
generated_code.write_to_file(PathBuf::from("generated.rs")).expect("Failed to write generated code to file.");
}
(Very similar to bindgen
)
I'll open an issue regarding code gen plugins/custom code gen, as it feels like a large issue that will need some careful consideration. --> https://github.com/jamiebrynes7/spatialos-sdk-rs/issues/117
That would require (and maybe this is already possible but not "first class") exposing the code generation as a library
This is kind of already a thing, in fact that's how cargo-spatial
does it. 😉 However, there would definitely be work required to build a nice user API and make writing plugins/extensions nice.
Hey!
That branch Jamie linked is just small changes needed for my specs integration. The actual project is https://github.com/samsnyder/spatialos-specs.
I did get it working but I am not maintaining it so I am not sure of the current state. Hopefully you will find it useful to try or look at though!
Amethyst is a game engine for rust which uses Specs as its entity-component-system implementation. Rather than trying to build a GDK, I'm exploring what it would take to integrate specs with the SDK provided by this repository.
As a first step, I'm going to try and accomplish this without any code-generation, just wrapping the spatial-generated components with a newtype struct that implements specs Component trait. Then, I'll implement generic component reader/writer Systems which interact with a mutex-protected WorkerConnection as a world resource.
Assuming that all of that goes well (and I'll share my results) the natural next step would be to auto-generate some implementations. Looks like this has been talked about in #83. Generating the systems isn't a big deal, but due to Rust's restriction that implementations for third-party traits must live alongside type definitions, the implementation of specs::Component for demo::Rotate would have to be part of the spatial codegen process.
At a high level, it would be nice to do something like
though I'm not sure how the custom generation code would be provided to the spatial cargo component.
How about using a build.rs file instead of a cargo component? That would require (and maybe this is already possible but not "first class") exposing the code generation as a library.