Skip to content

Commit

Permalink
[cairo] update port
Browse files Browse the repository at this point in the history
  • Loading branch information
codicodi committed Jan 26, 2017
1 parent add8ef9 commit 95b67ab
Show file tree
Hide file tree
Showing 4 changed files with 82 additions and 8 deletions.
67 changes: 65 additions & 2 deletions ports/cairo/CMakeLists_cairo.txt
Original file line number Diff line number Diff line change
Expand Up @@ -101,6 +101,8 @@ file(GLOB SOURCES
"cairo-tor-scan-converter.c"
"cairo-tor22-scan-converter.c"
"cairo-clip-tor-scan-converter.c"
"cairo-tag-attributes.c"
"cairo-tag-stack.c"
"cairo-toy-font-face.c"
"cairo-traps.c"
"cairo-tristrip.c"
Expand All @@ -127,6 +129,7 @@ file(GLOB SOURCES
"cairo-type1-subset.c"
"cairo-type3-glyph-surface.c"
# pdf
"cairo-pdf-interchange.c"
"cairo-pdf-operators.c"
"cairo-pdf-shading.c"
"cairo-pdf-surface.c"
Expand All @@ -140,6 +143,8 @@ file(GLOB SOURCES
"cairo-svg-surface.c"
# script surface
"cairo-script-surface.c"
# fontconfig + freetype
"cairo-ft-font.c"
)

set(CMAKE_DEBUG_POSTFIX "d")
Expand Down Expand Up @@ -222,11 +227,36 @@ endif()
add_library(user32 UNKNOWN IMPORTED)
set_property(TARGET user32 PROPERTY IMPORTED_LOCATION "${USER32_LIBRARY}")

# Find dependencies of optional modules

# Find FreeType
if(CMAKE_BUILD_TYPE STREQUAL Debug)
set(FREETYPE_SUFFIX d)
endif()
find_library(FREETYPE_LIBRARY freetype${FREETYPE_SUFFIX})
if (FREETYPE_LIBRARY MATCHES NOTFOUND)
message(FATAL_ERROR "The freetype library could not be found. Check to ensure that it is properly installed.")
endif()

# Cairo needs to be told which features of FreeType are availible
add_definitions(
-DHAVE_FT_GLYPHSLOT_EMBOLDEN=1
-DHAVE_FT_LIBRARY_SETLCDFILTER=1
-DHAVE_FT_GLYPHSLOT_OBLIQUE=1
-DHAVE_FT_LOAD_SFNT_TABLE=1
-DHAVE_FT_GET_X11_FONT_FORMAT=1)

# Find FontConfig
find_library(FONTCONFIG_LIBRARY fontconfig)
if (FONTCONFIG_LIBRARY MATCHES NOTFOUND)
message(FATAL_ERROR "The fontconfig library could not be found. Check to ensure that it is properly installed.")
endif()

if (VCPKG_LIBRARY_LINKAGE STREQUAL dynamic)
add_library(cairo ${SOURCES})
# cairo produces a lot of warnings which are disabled here because they otherwise fill up the log files
target_compile_options(cairo PUBLIC "/wd4244" PUBLIC "/wd4146" PUBLIC "/wd4312" PUBLIC "/wd4267" PUBLIC "/wd4996" PUBLIC "/wd4311" PUBLIC "/wd4334" PUBLIC "/wd4101")
target_link_libraries(cairo gdi32 msimg32 user32 zlib libpng pixman)
target_link_libraries(cairo gdi32 msimg32 user32 zlib libpng pixman ${FREETYPE_LIBRARY} ${FONTCONFIG_LIBRARY})

install(TARGETS cairo
RUNTIME DESTINATION bin
Expand All @@ -238,7 +268,7 @@ elseif (VCPKG_LIBRARY_LINKAGE STREQUAL static)
target_compile_options(cairo-static PUBLIC "/DCAIRO_WIN32_STATIC_BUILD=1")
# cairo produces a lot of warnings which are disabled here because they otherwise fill up the log files
target_compile_options(cairo-static PUBLIC "/wd4244" PUBLIC "/wd4146" PUBLIC "/wd4312" PUBLIC "/wd4267" PUBLIC "/wd4996" PUBLIC "/wd4311" PUBLIC "/wd4334" PUBLIC "/wd4101")
target_link_libraries(cairo-static gdi32 msimg32 user32 zlib libpng pixman)
target_link_libraries(cairo-static gdi32 msimg32 user32 zlib libpng pixman ${FREETYPE_LIBRARY} ${FONTCONFIG_LIBRARY})

install(TARGETS cairo-static
RUNTIME DESTINATION bin
Expand All @@ -248,3 +278,36 @@ elseif (VCPKG_LIBRARY_LINKAGE STREQUAL static)
else()
message(FATAL_ERROR "VCPKG_LIBRARY_LINKAGE is not defined or has an unexpected value")
endif()

# GObject support module

set(CAIRO_GOBJECT_SOURCES
"../util/cairo-gobject/cairo-gobject-enums.c"
"../util/cairo-gobject/cairo-gobject-structs.c")

# GObject support sources do not include header with export macro
if(BUILD_SHARED_LIBS)
set_source_files_properties(
"../util/cairo-gobject/cairo-gobject-enums.c"
"../util/cairo-gobject/cairo-gobject-structs.c"
PROPERTIES COMPILE_DEFINITIONS cairo_public=__declspec\(dllexport\))
endif()

# Make GLib's GObject available
find_library(GLIB_LIBRARY NAMES glib-2.0)
find_library(GOBJECT_LIBRARY NAMES gobject-2.0)
set(GLIB_LIBRARIES ${GLIB_LIBRARY} ${GOBJECT_LIBRARY})
if (GLIB_LIBRARIES MATCHES NOTFOUND)
message(FATAL_ERROR "The glib library could not be found. Check to ensure that it is properly installed.")
endif()

add_library(cairo-gobject ${CAIRO_GOBJECT_SOURCES})
if(BUILD_SHARED_LIBS)
target_link_libraries(cairo-gobject cairo ${GLIB_LIBRARIES})
else()
target_link_libraries(cairo-gobject cairo-static ${GLIB_LIBRARIES})
endif()
install(TARGETS cairo-gobject
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib)
4 changes: 2 additions & 2 deletions ports/cairo/CONTROL
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
9 changes: 9 additions & 0 deletions ports/cairo/cairo-features.h
Original file line number Diff line number Diff line change
Expand Up @@ -24,4 +24,13 @@
#define CAIRO_HAS_OBSERVER_SURFACE 1
#define CAIRO_HAS_USER_FONT 1

/* Require GObject */
#define CAIRO_HAS_GOBJECT_FUNCTIONS 1

/* Require FreeType */
#define CAIRO_HAS_FT_FONT 1

/* Require FontConfig */
#define CAIRO_HAS_FC_FONT 1

#endif
10 changes: 6 additions & 4 deletions ports/cairo/portfile.cmake
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,11 @@
#

include(vcpkg_common_functions)
set(SOURCE_PATH ${CURRENT_BUILDTREES_DIR}/src/cairo-1.14.6)
set(SOURCE_PATH ${CURRENT_BUILDTREES_DIR}/src/cairo-1.15.4)
vcpkg_download_distfile(ARCHIVE
URLS "https://www.cairographics.org/releases/cairo-1.14.6.tar.xz"
FILENAME "cairo-1.14.6.tar.xz"
SHA512 e2aa17a33b95b68d407b53ac321cca15b0c148eb49b8639c75b2af1e75e7b417a2168ea978dabb8581b341f0f45dc042d3b1a56b01ab525b1984015f0865316b
URLS "http://cairographics.org/snapshots/cairo-1.15.4.tar.xz"
FILENAME "cairo-1.15.4.tar.xz"
SHA512 ac3e6879fcf0876bca9f801cdf9e970ef1822644228cdd21962d0bf5db5fc074973f4ae651eb9c76b44fffd405cf0a0c7cbb228dba96b835ea137a2740277ee9
)
vcpkg_extract_source_archive(${ARCHIVE})

Expand Down Expand Up @@ -43,6 +43,8 @@ file(COPY
"${SOURCE_PATH}/src/cairo-svg.h"
"${SOURCE_PATH}/cairo-version.h"
"${SOURCE_PATH}/src/cairo-win32.h"
"${SOURCE_PATH}/util/cairo-gobject/cairo-gobject.h"
"${SOURCE_PATH}/src/cairo-ft.h"
DESTINATION
${CURRENT_PACKAGES_DIR}/include
)
Expand Down

6 comments on commit 95b67ab

@mikebmcl
Copy link
Contributor

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.

@codicodi
Copy link
Contributor Author

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.

@ras0219-msft
Copy link
Contributor

@ras0219-msft ras0219-msft commented on 95b67ab Feb 18, 2017

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:

  • Vcpkg does not make any attempt to track ABI compatibility between different package versions. Internally, we mandate that every package be rebuilt from source if any dependency version strings are bitwise different.
  • We generally want to prefer the latest "stable" release, where stable means that if the upstream project has a set of release gates that are tested only sometimes (maybe they don't do stress testing in their CI), we would like to prefer local "maximums" of quality. We don't specifically mean "stable releases" to imply ABI/API suitability, though those are nice-to-haves.
  • We care very deeply about ecosystem. If the larger community of libraries and applications depending on a package have centralized on a particular version, we prefer to pick that version (even if it's newer/older than the official "release"). In the case of Ogre, this means our version is quite out-of-date -- every version after it has had constant high API churn that prevents (very real) plugins and other libraries from being updated.
  • For users who need strong consistency guarantees, we don't believe that an intention of ABI stability from upstream is sufficient (it's often not even available!). We instead intend the repository to be forked and frozen at some particular commit. Upgrades become very explicit and opt in, by actually pulling individual version of the 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 of cairo, 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 via git 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 a cairo_1_14 or cairo_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?

@mikebmcl
Copy link
Contributor

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.

@ras0219-msft
Copy link
Contributor

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.

@mikebmcl
Copy link
Contributor

@mikebmcl mikebmcl commented on 95b67ab Feb 18, 2017

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

Please sign in to comment.