use of the Requires.private field
Dan Nicholson
dbn.lists at gmail.com
Sat Jun 19 08:28:25 PDT 2010
On Sat, Jun 19, 2010 at 2:16 AM, Andreas Metzler
<ametzler at downhill.at.eu.org> wrote:
> Dan Nicholson <dbn.lists at gmail.com> wrote:
>> On Thu, Jun 17, 2010 at 2:35 PM, Vincent Torri <vincent.torri at gmail.com> 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:
>
>> http://people.freedesktop.org/~dbn/pkg-config-guide.html
>
>> 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
libraries.
Please read the next section of the guide. It explains this pretty explicitly.
http://people.freedesktop.org/~dbn/pkg-config-guide.html#writing
--
Dan
More information about the pkg-config
mailing list