-
Notifications
You must be signed in to change notification settings - Fork 12
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
compile: Upgrade to bindgen 0.61
and use Builder
with Clone
#22
compile: Upgrade to bindgen 0.61
and use Builder
with Clone
#22
Conversation
Commit ad85f13 ("Seems like edition in workspace isn't applied? Update all to 2021") found that `workspace.edition` isn't a valid key and added it to most crates' individual `[package]` table, but didn't remove the key from `[workspace]` nor added it to the `compile` and `runtime` crates. Note that `[workspace.package] edition = "2021"` exists since Rust 1.64, but still requires `[package] edition.workspace = true` to be repeated in every individual `Cargo.toml` for it to be inherited: https://doc.rust-lang.org/cargo/reference/workspaces.html#the-package-table
As announced earlier in Twinklebear#20 when introducing `BindgenOptions`, upstream `bindgen` didn't yet allow cloning nor copying their `Builder` struct, limiting it to generate a single binding per `Builder` object. This doesn't fit with ispc-rs's `Config` struct which explicitly allows multiple libraries to be compiled using (partially) the same base configuration (barring any side-effects from `fn compile(&mut self, lib)` updating various fields depending on `lib`). This issue has since been addressed upstream, and now allows us to move and clone the `bindgen::Builder` around instead of implementing a very limited subset of config fields and manually reconstructing the builder every time.
In hindsight I'm not really sure if it was/is a good idea to expose the entire bindgen At the same time updating this
Perhaps we should refactor this. |
Thanks @MarijnS95 ! I think this will work well to expose the full bindgen options so that people can control whatever bindgen settings they want to without having to request each one to be added to ispc-rs. The best way to build things/clone/reuse/etc will depend on what different app's build configurations are like so just exposing the options is a good path. Good point about the side effects in |
I'm not sure if we'd want to make the additional fixes to make |
@Twinklebear Perhaps a good idea to fold in those changes at the same time, assuming they may be breaking as well? |
Yeah, that's my thought as well. I should have some time to make those changes this week/weekend |
@Twinklebear Thanks! Better if you look into it 👍 |
@MarijnS95 just to give you a heads up, I made that last change to the |
We landed some nice changes to smooth out `bindgen::Builder` usage with `bindgen 0.61` 🎉: Twinklebear/ispc-rs#22
@Twinklebear thanks a ton! I've just upgraded our crates to use the new release and it all seems to work great! Immutability changes look great too! |
We landed some nice changes to smooth out `bindgen::Builder` usage with `bindgen 0.61` 🎉: Twinklebear/ispc-rs#22
* Upgrade `ispc-rs` to `2.0.0` We landed some nice changes to smooth out `bindgen::Builder` usage with `bindgen 0.61` 🎉: Twinklebear/ispc-rs#22 * Fix stricter `clippy::needless_borrow` lint and clean up some existing code * Clean old artifacts * CI/generate-binaries: `{}` glob pattern not supported in upload-artifact https://github.com/actions/toolkit/tree/main/packages/glob#patterns * Update binaries from CI
Depends on #21 for
pub use bindgen;
(perhaps allextern crate
should be replaced since moving to edition 2021?)As announced earlier in #20 when introducing
BindgenOptions
, upstreambindgen
didn't yet allow cloning nor copying theirBuilder
struct, limiting it to generate a single binding perBuilder
object. This doesn't fit with ispc-rs'sConfig
struct which explicitly allows multiple libraries to be compiled using (partially) the same base configuration (barring any side-effects fromfn compile(&mut self, lib)
updating various fields depending onlib
).This issue has since been addressed upstream, and now allows us to move and clone the
bindgen::Builder
around instead of implementing a very limited subset of config fields and manually reconstructing the builder every time.