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. 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. 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. 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. 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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel