-
-
Notifications
You must be signed in to change notification settings - Fork 636
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
Extract cbindgen'd interface into its own crate #8013
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome.
# We need to parse the engine crate to codegen PyResult (because externs are both something we use | ||
# from Python in engine, and something we expose to python in engine_cffi). | ||
# | ||
# We need to parse the logging crate to codegen PythonLogLevel and Destination. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should mention the list in engine_cffi/build.rs
, and vice-versa.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have as much time as I'd want to right now to go over this, but I'm extremely excited about this change, and I believe it can close #8009! Thank you so much!
I think ideally I would've moved the engine crate out into a new
subcrate, but this way around better preserves git history and avoids
merge conflicts.
I think I agree with this, but I also feel like separating the ffi interface specifically into a subcrate makes a lot of sense by itself as an incremental step. I'd love to have an interface to other languages at some point.
This means that we compile engine before we try running cbindgen over it, so we get useful parse errors out of rustc, rather than errors manifesting themselves as cbindgen going "There was a parse error somewhere!" I think ideally I would've moved the engine crate out into a new subcrate, but this way around better preserves git history and avoids merge conflicts.
ed24aa2
to
4720f06
Compare
This means that we compile engine before we try running cbindgen over it, so we get useful parse errors out of rustc, rather than errors manifesting themselves as cbindgen going "There was a parse error somewhere!" I think ideally I would've moved the engine crate out into a new subcrate, but this way around better preserves git history and avoids merge conflicts.
This means that we compile engine before we try running cbindgen over
it, so we get useful parse errors out of rustc, rather than errors
manifesting themselves as cbindgen going "There was a parse error
somewhere!"
I think ideally I would've moved the engine crate out into a new
subcrate, but this way around better preserves git history and avoids
merge conflicts.