[PATCH weston sdk v2 1/8] weston.pc: Add dependencies for pixman-1 and xkbcommon

[Kristian Høgsberg]

On Thu, Jul 4, 2013 at 12:35 PM,  <sardemff7+wayland at sardemff7.net> wrote:
> 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.

The way pkg-config used to work was that Requires.private was for
libraries you linked to, but didn't expose in your API.  For example
libpng links to libz but doesn't expose that in its API.  Applications
don't need to link to libz or know the right include paths in case of
dynamic linking.  However, for static linking, you need to link to all
libraries that you or and library that you depend on, which is why
Private.requires was introduced.  That still sounds like it's
consistent with the pkg-config guide you link to below.

>> 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.

That's new behavior, but you're right, I checked.

>> 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.

And that's exactly why I want it to be plain Requires.  pixman isn't
an implentation detail of weston, the pixman API is part of the weston
plugin API.  When a module links to weston, it doesn't need to
additionally use pkg-config to discover pixman libs and cflags, that
should come from the weston.pc requirements.  As for the libxkbcommon
case, direct linking wont help you if weston isn't compile with
support for libxkbcommon, you need the functionality to be available
in weston and weston to link libxkbcommon for any libxkbcommon use to
make sense in a module.

Kristian