Bug 18815

Summary:	Add Requires.cflags
Product:	pkg-config	Reporter:	Behdad Esfahbod <freedesktop>
Component:	src	Assignee:	Tollef Fog Heen <tfheen>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium	CC:	bohan.freedesktop, daniel.kitta, lool, mar-UCxYQJ
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:	63747
Bug Blocks:

Description Behdad Esfahbod 2008-11-29 16:55:53 UTC

According to Loïc Minier [1] pkg-config was recently modified to recursively collect the cflags of Requires.private modules referenced.  I believe using Requires.private for two completely separate purposes (libraries to be linked statically, and cflags needed for our headers) is totally bogus.

I suggest that the Requires.private change be reverted and a new tag Requires.cflags be added that only fetches cflags of the modules.  For symmetry a Requires.libs tag may as well be added.  To keep backward compatibility, you can leave Requires.private alone and add Requires.libs.private with the new semantics.

The use cases for Requires, Requires.cflags, and Requires.libs.private are very clear and separate:

  - Requires: "cairo-xlib" for example requires "cairo" and "xlib".  It makes little sense to be using cairo-xlib functions but not linking to cairo and xlib.  Though it's not impossible.  This is more of a convenience case.

  - Requires.cflags: Used with modules that we use (as in #include) in our public headers.  For example, "vte.h" includes "pango.h", "gtk.h", and "glib.h", but it's understandable that not every vte-using application may use those libraries.  So vte must Requires.cflags: pango gtk glib, to not force linking to those.

  - Requires.libs.private: This is completely implementation details of the module.  For example, harfbuzz may use glib internally, but it doesn't expose any glib-related api nor does it include glib.h from its public headers.  The only use for making this information available to users of harfbuzz is solely for static linking purposes.


Cheers,

behdad

[1] http://bugzilla.gnome.org/show_bug.cgi?id=322240

Comment 1 Daniel Macks 2009-08-15 12:35:09 UTC

This idea for a way to separate public from private external headers requirements is a good idea IMO, and would save tons of headaches for downstream package-management systems. Debian and others have separate "-dev" packages (with headers and other compile-time files, such as .pc) to accompany library packages. If I am packaging a program, it's easy for me to see what compile-time dependencies I functionally need to specify: whatever supplies any header I use (easy to determine using autoconf's --enable-dependency-tracking) and whatever libs I link against (easy to determine using ldd or similar tricks). Those also find my public indirect dependencies: headers of third-party pkgs used by headers I use directly and dependent libs published by direct deps.

Truly "private" headers (internal implementation only, not "internal but used in public headers") are not revealed by this approaches because duh, they're not public. But I (as packager) still need to specify compile-time dependencies on them, otherwise PKG_CONFIG_MODULES will fail (because unable to resolve .pc in the the .private dependency chain). As far as I can tell, there is *no* way to reveal this internal dep, so it's hard for package-maintainers to create packages. Also, every time an implementation of a lib changes its totally private dependnecies, all packages that use that lib risk being broken because they suddenly are missing a build-time dependency.

I completely recognize the need to separate dependent-lib vs dependent-header and why there needs to be a way to specify that latter (i.e., why the current .private implementations are rational). But more, I agree with this bug report that the current way still at best mixes up two different tasks. And I think the idea of having real "static-linking-only" flags and dependencies for internal-implementation-only details is an important missing feature.

Comment 2 Dan Nicholson 2013-04-20 02:01:36 UTC

I think this is something pkg-config is sorely missing. My idea is slightly different, though. I think it would be better if Requires and Requires.private just became more expressive by qualifying the required package. For example, Requires: Cflags(foo), would pull in just the Cflags from the foo package and not the link flags. This could also work on the command line: "pkg-config --cflags --libs Cflags(foo) bar", which in turn would be usable from PKG_CHECK_MODULES. I found that I needed this myself a while ago when I was developing a Mozilla plugin and just wanted the NPAPI headers and not to actually link with libxpcom. This would also fix the longstanding bug 4738.

However, I'm uneasy about adding new metadata fields since we currently have no mechanism to signal that a newer pkg-config is needed to parse the .pc file. In other words, this would break when users have an older pkg-config.

I've opened bug 63747 to track writing a spec for the current metadata syntax to open the doors for extending it. I've made this bug blocked by it.

Comment 3 Martin Hostettler 2018-03-18 19:36:20 UTC

Something similar but without breaking backwards compatibility is discussed in
https://bugs.freedesktop.org/show_bug.cgi?id=105572

Comment 4 GitLab Migration User 2018-08-25 12:54:26 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pkg-config/pkg-config/issues/23.

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.