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

[Pekka Paalanen]

On Thu, 04 Jul 2013 13:18:27 -0700
Thiago Macieira <thiago.macieira at intel.com> wrote:

> On quinta-feira, 4 de julho de 2013 18.35.16,
> sardemff7+wayland at sardemff7.net wrote:
> > > 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.
> 
> See below.
> 
> > > 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.
> 
> I partially agree. If I know in my API that I am using both libs X
> and Y, I should tell my buildsystem so.
> 
> But there are cases when I don't know of the indirect dependency. I'm
> using X, and I'm not using any of Y's API. Yet to compile my
> application, X requires Y's headers. That means X's .pc file should
> declare it depends non-privately on Y.
> 
> This is especially the case in C++, when base classes, operators,
> constructors and other things can hide from you the fact that you're
> using some other library.
> 
> > A plugin is using libxkbcommon for a feature, but provides several
> > more. Weston is build with libxkbcommon support. All is fine.
> 
> Yes.
> 
> > 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.
> 
> Agreed: the plugin should declare explicitly. If a project uses
> intentionally a library, it should declare explicitly the dependency.
> 
> But I also disagree: if libweston's public API headers include
> unconditionally some other library's headers, libweston's .pc file
> should declare the public dependency. Otherwise, no plugin will
> compile.
> 
> Of course, there's also a grey area: an optional feature. Suppose
> that there's exactly one Weston header that requires xkbcommon and
> that header is not included by any other: weston-xkbcommon.h. In that
> case, anyone who uses that header is intentionally depending on
> xkbcommon. So in that case, weston.pc doesn't declare the public
> Requires.

The color management modules are an example of a weston module, that
does not need pixman at all. If you grep through src/cms*.[ch], there
is not a single mention of "pixman". Why do these modules, if they were
external, need to link directly to pixman then?

This is C, not C++. There are no macros or inline functions in the
headers that would call any library functions. There is no "indirect
dependency".

Requires.private will provide the needed CFLAGS.

I still do not see any techinal reason to use Requires instead of
Requires.private, but if it's a convention, future-proofing, or for
supporting old versions of pkg-config, then I understand. All the
technical rationale however say that you should be using
Requires.private here. I just wanted to hear the real reason for this.

Sounds like this is really a convention: we assume, that a weston
plugin will be using all of the exposed APIs, which roughly implies,
that it will need to call into those libraries itself. With that
assumption in place, Requires makes sense.


Thanks,
pq