On 04/07/2013 18:25, Thiago Macieira wrote:
On quinta-feira, 4 de julho de 2013 10.12.05, Pekka Paalanen wrote:
On Wed, 3 Jul 2013 18:26:06 -0400
No, it has to be plain Requires.  By having pixman and libxkbcommon
headers in our SDK headers, we expose those dependencies to
applications.

Hi,

could you explain that logic a bit more?

Is it just a convention to use Requires for header dependencies instead
of Requires.private, or does simply including SDK headers in a project
actually add a hard link time requirement to these libs, or are
Requires being used for distribution package dependencies while
Requires.private are not?

It's not a convention. This is required for proper builds to work.

No. Check my previous mail on this issue, please.


Suppose that our headers #include headers from a project whose headers aren't
usually in /usr/include (that is, they require -I). In order for our users'
applications to build, they need to add those -I as well. The Requires is what
tells pkg-config to add them.

Requires.private too.


What's more, even if the include paths are not an issue, the linking could be.
Since we included some third party API in our API, it's conceivable that users
might need to call functions in those libraries. If that happens, then user
applications must also link directly to the libraries, not indirectly only.

And they must link directly! That is the proper way to do that. Providing API using these libraries does not mean forcing anyone to use that. And using a library does require linking to it. Hiding this dependency inside "libweston" is error-prone. I was going to speak conditionally, but now it is the case so check that: A plugin is using libxkbcommon for a feature, but provides several more. Weston is build with libxkbcommon support. All is fine. Now, the same plugin is build against a non-libxkbcommon Weston (this is the now-possible case): it will break badly.
Explicit usage is the way. Period.


Requires.private is used to list other packages that are "privately" used.
That is, libraries and frameworks that are not exposed in the API, which means
that users our *our* API will not be exposed to the third-party API, so they
won't need the -I/-L/-l flags at all.

Sure, but read this pkg-config guide too: http://people.freedesktop.org/~dbn/pkg-config-guide.html


You may ask then, why list at all the privates? Well, there's one case where
the user needs the -L/-l flags: when our API is provided as a static library.
It's probably not going to be the case for Weston, since the point of linking
is to provide plugins and those make no sense in static builds.

The point will be when libweston will exist.


--

Quentin “Sardem FF7” Glidic
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to