Skip to content
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

Add vendored cairo-sys-rs crate #4174

Merged
merged 1 commit into from
Aug 21, 2023
Merged

Add vendored cairo-sys-rs crate #4174

merged 1 commit into from
Aug 21, 2023

Conversation

wez
Copy link
Owner

@wez wez commented Aug 20, 2023

I'm experimenting with using cairo's 2D graphics for glyph related drawing operations, and perhaps more stuff in the UI in the future.

The challenge is that no one has yet encapsulated its build in a cargo-friendly way.

This commit is that attempt.

The strategy is this:

  • deps/cairo is ostensibly the same thing as https://github.com/gtk-rs/gtk-rs-core/tree/master/cairo/sys which is the cairo-sys-rs crate
  • Its build.rs has been replaced with a version that builds from the C sources that are found in-tree; it will never look for the system cairo library
  • A pair of scripts to import pixman (a required dep of cairo) and cairo itself in a repeatable way are include, for if/when we need to update the vendored sources Cairo is a mature library and doesn't release very often.
  • The workspace sets a patch for crates.io so that cairo-rs has its cairo-sys-rs dep redirected to the local build.

I'm not planning to upstream this stuff to gtk-rs-core as full cairo depends on a lot more things than are dealt with here, so it would be a PITA to handle that generally.

This vendoring strips out things that are not used, so the cairo library that remains:

  • Is not internally thread safe; no TLS or mutex support is enabled in either of them. That's fine because the high level cairo-rs wrapper is not Send+Sync, which means that rust will only allow it to be used single threaded anyway.
  • Only has the basic recording and image surfaces
  • No platform support for win32/xlib/xcb and so on

@wez wez force-pushed the cairo branch 2 times, most recently from 80ce305 to bcdb523 Compare August 20, 2023 21:45
I'm experimenting with using cairo's 2D graphics for glyph related
drawing operations, and perhaps more stuff in the UI in the future.

The challenge is that no one has yet encapsulated its build in a
cargo-friendly way.

This commit is that attempt.

The strategy is this:

* `deps/cairo` is ostensibly the same thing as https://github.com/gtk-rs/gtk-rs-core/tree/master/cairo/sys
  which is the cairo-sys-rs crate
* Its build.rs has been replaced with a version that builds from the C
  sources that are found in-tree; it will never look for the system
  cairo library
* A pair of scripts to import pixman (a required dep of cairo) and
  cairo itself in a repeatable way are include, for if/when we need
  to update the vendored sources
  Cairo is a mature library and doesn't release very often.
* The workspace sets a patch for crates.io so that cairo-rs has
  its cairo-sys-rs dep redirected to the local build.

I'm not planning to upstream this stuff to gtk-rs-core as full cairo
depends on a lot more things than are dealt with here, so it would be a
PITA to handle that generally.

This vendoring strips out things that are not used, so the cairo
library that remains:

* Is not internally thread safe; no TLS or mutex support is enabled
  in either of them. That's fine because the high level cairo-rs
  wrapper is not Send+Sync, which means that rust will only allow
  it to be used single threaded anyway.
* Only has the basic recording and image surfaces
* No platform support for win32/xlib/xcb and so on
@wez wez merged commit 58a2a30 into main Aug 21, 2023
17 checks passed
@wez wez deleted the cairo branch August 21, 2023 06:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant