-
Notifications
You must be signed in to change notification settings - Fork 231
Move harfbuzz-traits implementations into component crates
#7200
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
Conversation
7071d22 to
e6d9e8f
Compare
e6d9e8f to
5acb904
Compare
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.
Seems good to eliminate a leaf crate. Can we avoid growing the boilerplate in examples/cargo/harfbuzz?
|
the boilerplate in the example is additional example code for using buffer providers, as well as the ZST box optimization that not relevant to all HarfBuzz implementations (the harfbuzz crate needs it because it needs to box over FFI). |
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.
Overall in favor of this!
@hsivonen wrote this, we should probably wait for him to check in
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.
Would still prefer that @hsivonen sign off on this being removed.
|
Moving the trait implementations seems OK. It would be good to publish a tombstone release of |
|
That's a good point. @robertbastian can you do that after merging this? (my r+ stands, feel free to merge) |
|
I filed #7210 because we can only do this after 2.2. |
icu_propertiesalready does this forunicode-bidi. The currenticu_harfbuzzcrate is written for use with theharfbuzzcrate, however there are other Rust HarfBuzz implementations that don't need the code in that crate.