After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 352189 - gtk interface doesn't seem to depend on cairo
gtk interface doesn't seem to depend on cairo
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: Other
2.8.x
Other All
: Normal trivial
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2006-08-20 20:53 UTC by Samuel Thibault
Modified: 2006-12-29 20:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Samuel Thibault 2006-08-20 20:53:41 UTC
Hi,

in gtk+-2.0.pc.in, one can read

Requires: gdk-${target}-2.0 @GTK_PACKAGES@

which expands to

Requires: gdk-${target}-2.0 atk cairo

But when reading gtk headers, one can't find a single mention of cairo. Gtk itself uses cairo, but it shouldn't expose it externally. The gtk dependency should hence be split into

Requires: gdk-${target}-2.0 atk
Requires.internal: gdk-${target}-2.0 @GTK_PACKAGES@
Comment 1 Samuel Thibault 2006-08-20 20:54:52 UTC
(Note: just the same for gtk+-x11-2.0)
Comment 2 Owen Taylor 2006-08-21 02:04:37 UTC
While it's certainly possible to write a GTK+ program that doesn't
depend on cairo:

 #include <gtk/gtk.h> does pull in cairo.h via GDK, and we won't remove that 
 cairo is *the* recommended drawing interface for GTK+
 We don't think people should need to specify another header
 We don't think people should need to specify another .pc file
Comment 3 Samuel Thibault 2006-08-21 08:26:36 UTC
> While it's certainly possible to write a GTK+ program that doesn't depend on
> cairo:
> 
>  #include <gtk/gtk.h> does pull in cairo.h via GDK, and we won't remove that
>  cairo is *the* recommended drawing interface for GTK+

Agreed.

> We don't think people should need to specify another header

Agreed.

> We don't think people should need to specify another .pc file

Agreed.

And that's why pkgconfig flags are transitive: since gtk+-2.0.pc Requires gdk-${target}-2.0, and gdk-${target}-2.0 Requires cairo, cairo flags get added. But gtk+-2.0.pc itself should _NOT_ directly Requires cairo, or any other library that it uses internally, but doesn't expose _itself_ directly (this should be put in Requires.internal instead).

Just try if you don't believe me (or read the documentation): move @GTK_PACKAGES@ to Requires.private in gtk+-2.0.pc (but keep atk in Requires, since its interface is exposed), and you'll still get cairo from pkg-config gtk+-2.0 --cflags
Comment 4 Samuel Thibault 2006-08-21 08:31:58 UTC
Note: I'm not telling only about cairo, but about any library that might end up in @GTK_PACKAGES@.
Comment 5 Owen Taylor 2006-08-21 14:24:58 UTC
OK, I thought you meant remove the cairo from GDK as well as GTK+.

Removing the cairo dependency from GTK+ while leaving it for GDK, is uh, I guess
OK, but pretty much completely irrelevant.

(I would consider it bad form to put the cairo dependency of GTK+ in 
Requires.private in that case, however, since the whole point in having
cairo in the Requures: of GDK is so that things that depend on GDK
don't have to depend on cairo as well...)
Comment 6 Matthias Clasen 2006-12-29 19:47:34 UTC
Doesn't seem worth it.
Comment 7 Samuel Thibault 2006-12-29 20:40:28 UTC
Ask a debian buildd maintainer who has to recompile a big bunch of packages just because of _one_ library upgrade...

In this precise case, using Requires.private for cairo indeed won't change anything since it is already exposed through gdk/pangocairo, but GTK_PACKAGES may contain other packages someday (and then this bug will have to be re-opened).