-
Notifications
You must be signed in to change notification settings - Fork 6.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
4 changed files
with
82 additions
and
8 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,4 +1,4 @@ | ||
Source: cairo | ||
Version: 1.14.6 | ||
Version: 1.15.4 | ||
Description: Cairo is a 2D graphics library with support for multiple output devices. Currently supported output targets include the X Window System (via both Xlib and XCB), Quartz, Win32, image buffers, PostScript, PDF, and SVG file output. Experimental backends include OpenGL, BeOS, OS/2, and DirectFB. | ||
Build-Depends: zlib, libpng, pixman | ||
Build-Depends: zlib, libpng, pixman, glib, freetype, fontconfig |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
95b67ab
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 commit updated the package from a stable release to an "in-progress" snapshot. See: https://www.cairographics.org/download/ . The snapshots do not have the API stability guarantees that the releases have. Changing this port from stable releases to unstable snapshots changes the nature of the port itself.
As such, I would strongly recommend backing out this commit. If there is a desire to have the cairo snapshots available using vcpkg, there should be a separate port for it. It would be easy, since it would be this port, including this commit, with a different name. Cairo does evolve and indeed this port should be updated to 1.14.8 (the latest stable release). Eventually there will be 1.16.x releases (even numbers are stable) and I expect this port will be updated to those.
Regardless, when I initially created this port it was to make using stable releases of cairo easier. There were snapshots available at that time and the decision not to use them was intentional. I appreciate the work; I just strongly believe that it should be in a different port so that this will always provide only stable releases of cairo.
95b67ab
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.
Hi, @mikebmcl, I explained reasoning behind this update in #596. Basically, GTK+ (whitch I'm currently trying to package) won't build on Windows with 14.x cairo since quite a few (stable) releases.
95b67ab
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.
Without pointing to a particular solution, I would like to make the following notes:
ports\<package>\
directory and checking them in locally. We enable this workflow by only using checked-in information to perform the builds -- you can fork Vcpkg, change whatever you like, and the results will be consistent and reproducible, exactly as though you had checked in the source code for the libraries themselves. In the particular case ofcairo
, if we did not roll back this upgrade, you could fork and revert this commit -- in the future, git will still allow you to get updates viagit pull
, and you'll be notified with a merge conflict if we make additional changes to the cairo port and have the option of backporting them (e.g. there's a bug in our install process that missed an often-used header file).Given the above stances, I would lean towards having the
cairo
port be pointing at the 1.15 series of snapshots (and then upgrading to 1.16 as soon as available). If there are important libraries that only support the 1.14 series, and don't intend to support 1.15, I could see a need for acairo_1_14
orcairo_stable
package that does track the 14 release series. Because the development files aren't side-by-side deployable, we wouldn't have a good experience around this today (see #249, #164, and #25 for relevant discussion on improving this situation).Could you fill in some more context around why you'd like to see 1.14 as the default? You mentioned ABI stability, so are you attempting to port/service some existing application onto Vcpkg without rebuilding it?
95b67ab
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 was mostly just concerned about the API stability and potential code quality. I hadn't seen the reasoning for moving to 1.15. It's persuasive enough for me on both issues. The only API things that might change in cairo are the new features. Otherwise they have a very strong commitment to backward compatibility. And given how many well known and widely used projects have taken a dependency on it, I'm not really worried that there might be QOI issues with the snapshot.
95b67ab
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.
Great.
Thank you very much for bringing this up -- if you see any other packages we may have mistreated in this way, it's always valuable to reaffirm why we're doing things and to improve if possible!
For now then, conclusion is no change.
95b67ab
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.
Just as a last note. The reason for my interest in this is that I'm the primary author of P0267R3, PDF file, which is "A Proposal to Add 2D Graphics Rendering and Display to C++".
I also wrote and maintain the reference implementation of the proposal https://github.com/mikebmcl/N3888_RefImpl. I created the cairo and pixman ports so that I could switch to use vcpkg for Windows builds. I haven't done a recent pull in order to test it against the 1.15 branch yet but I plan to shortly.
If it turns out that there are significant issues, I'll likely create a "cairo-stable" or "cairo_1_14" port and submit a PR (note: as I discuss below, what I would actually do is use my fork to stick to 1.14 since there doesn't seem to be a better workaround to issue #25 for my purposes). I'm not anticipating any real issues, but when 1.14 was released I did have a minor issue because a cairo enum added an extra member and my code was a bit brittle such that I had to apply a fix on my end.
Anyway, if I do have real, non-trivial issues my preference is a "cairo-stable" port (and I'll deal with any 1.16 issues when that branch is released). But naming is important so if you have any "just in case" feedback on that, I'd be grateful.
Indeed, I kind of think that this is an issue that applies to vcpkg in general rather than just cairo. So maybe going with a "major release" naming scheme, i.e. "cairo_1_14" would be better.
An official policy on this would be good.
It wouldn't resolve (or seem to have anything to do with) issue #249.
From a cursory read of issue #164, it seems like the issues raised there might apply here if someone tries a side-by-side install of both (at this point hypothetical) packages that would provide different versions of cairo.
Issue #25 - I read them in the order you linked them - is exactly a discussion of this (hypothetical for cairo) problem. As such, if I need cairo 1.14, I'll use my fork of vcpkg and keep it up-to-date except for cairo. That seems like the best current workaround for the issue #25 problems.
Hopefully there will be a better solution in the future. If/when I have thoughts on the issue, I'll post them there rather than here. I would've done so with this post but this post is still cairo-specific. But this is the last cairo-specific post I expect to write regarding versioning. Thank you for your indulgence.
Best regards,
-Mike