use of the Requires.private field

Dan Nicholson dbn.lists at
Sat Jun 19 08:28:25 PDT 2010

On Sat, Jun 19, 2010 at 2:16 AM, Andreas Metzler
<ametzler at> wrote:
> Dan Nicholson <dbn.lists at> wrote:
>> On Thu, Jun 17, 2010 at 2:35 PM, Vincent Torri <vincent.torri at> wrote:
>>> Hey,
>>> We have 2 libraries, named Eina and Evas. Eina is some kind of data types
>>> lib. Evas depends on Eina. Hence, Eina is "public". Its types are used in
>>> the API and we have, for example, in Evas.h (the public header)
>>> #include <Eina.h>
>>> The .pc file of Eina is named eina-0.pc
>>> My question is:
>>> should I put eina-0 in the Requirements field, or in the
>>> Requirements.private field ?
>> Requires.private. You need to make sure that users get the Cflags from
>> Eina for the datatypes, but they don't need to explicitly link to Eina
>> unless they're statically linking. See FAQ #2 here:
>> This guide is also in the latest pkg-config release if you have it.
> Quote
> "Requires.private: A list of private packages required by this package
> but not exposed to applications."
> Unquote
> If Evas.h  includes <Eina.h> then evas *does* expose Eina's API to the
> application.

Sorry, the wording there isn't entirely accurate. In this case,
"exposed to applications" refers to symbols. As in, Evas does not use
Eina in such a way that it would require me to explicitly link my app
to Eina. In fact, there's probably no reason to use Requires for a C
library unless you just want to force people to link to your required

Please read the next section of the guide. It explains this pretty explicitly.


More information about the pkg-config mailing list