pkg-config 0.18 adds a new "Requires.private" header for .pc files that would be useful to use in Cairo. The semantics of this header are: 1) when verifying that a package and it's dependencies are available, its contents get merged with "Requires" 2) when expanding the includes list with "pkg-config --cflags", its contents are ignored. 3) when expanding the libs list with "pkg-config --libs", its contents are ignored if the platform supports dynamic library dependencies. 4) when expanding the libs list with "pkg-config --static --libs", its contents are merged with "Requires" i.e. it is intended to list dependencies of a library that are not exposed through the library's API. In the case of Cairo, the PNG library and libpixman fall into this category. By moving those two to Requires.private, applications don't end up depending on a particular soname for those libraries -- only libcairo.so would need to be updated. The following diff makes the change: Index: cairo.pc.in =================================================================== RCS file: /cvs/cairo/cairo/cairo.pc.in,v retrieving revision 1.20 diff -u -p -r1.20 cairo.pc.in --- cairo.pc.in 24 Feb 2005 16:20:14 -0000 1.20 +++ cairo.pc.in 30 Jun 2005 06:52:02 -0000 @@ -7,6 +7,8 @@ Name: cairo Description: Multi-platform 2D graphics library Version: @VERSION@ -Requires: @FREETYPE_REQUIRES@ libpixman @XRENDER_REQUIRES@ @PNG_REQUIRES@ @GLITZ_REQUIRES@ +Requires: @FREETYPE_REQUIRES@ @XRENDER_REQUIRES@ @GLITZ_REQUIRES@ +Requires.private: libpixman @PNG_REQUIRES@ Libs: @FREETYPE_LIBS@ -L${libdir} -lcairo Cflags: @FREETYPE_CFLAGS@ -I${includedir}/cairo + Note that there is a pretty big downside to this change though: versions of pkg-config <= 0.15 generate an error if they see an unknown header, so the .pc file would be incompatible with those versions. For versions < 0.18 the .pc file would work mostly, but the PNG and libpixman versions would not be checked during configure. So it might be worth considering this change sometime in the future rather than now.
I just noticed that cairo had been updated to optionally use Requires.private if pkg-config >= 0.18 was being used. Unfortunately, the change does not quite look correct: if a dependent package's API is exposed through your API, then it should be listed under "Requires" rather than "Requires.private". Otherwise you might not be able to #include the Cairo headers because the required includes are not given. In the patch I gave with the first comment, the only libraries I moved were libpixman and libpng. This is because both of those libraries are completely encapsulated by the Cairo API. This is not the case for the other dependencies.
That sounds like a valid bug to me. Keith did this rework, so I'm sending this his direction.
I placed these in Requires.private as any application using these functions will have to link in those libraries in any case, and will hence need an explicit dependency to build. I wanted to make it possible to build an Xlib-based application against an Xlib+Glitz cairo and then run it against a pure Xlib-based cairo, in this case the spurious glitz dependency would be annoying (and wrong). This should work, right?
Putting all the libraries in Requires.private will stop pkg-config from adding glitz, etc to the link line. However, I think mainline libtool will still add the missing libraries to the link line (because they are listed in the libtool .la file). If you want to make absolutely certain that cairo users don't explicitly link to glitz, you'll need a script to modify the .la files post build like Owen wrote for Pango: http://cvs.gnome.org/viewcvs/*checkout*/pango/sanitize-la.sh?view=markup See pango/Makefile.am for how it is used (through the install-exec-hook target).
Yes, libtool remains a problem with broken .la files. I've actually created a local version which does not install those at all and have saved myself quite a bit of grief in the process. At this point, I'm uncertain whether to stop using libtool or not; with pkg-config solving the dependency problem, it doesn't seem like libtool is really helping enough to make up for the endless troubles it causes.
Move bugs against "cvs" version to "0.9.3" so we can remove the "cvs" version.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.