Requires.private behaviour and usage.

Dan Nicholson dbn.lists at
Fri Feb 27 09:32:15 PST 2009

On Fri, Feb 27, 2009 at 8:18 AM, Nicolas Chauvet <kwizart at> wrote:
> So, what I would propose as a fix would be to deprecate
> Requires.private alone, and to split Requires.Cflags from
> Requires.private (it will assume that Requires.private behaviour will
> change).

I don't think the Requires.private behavior can be changed. That's
will just break a lot of things and cause chaos. Requires and
Requires.private mean that you want the Cflags and Libs* from
dependent packages. Period. However, I think it would be good to
reflect that you need to require a package, but only for specific
parts. So, I think three new fields would be good (for completeness):

Requires.cflags - Cflags from listed packages and their
Requires/Requires.private/Requires.cflags packages

Requires.libs - Libs/Libs.private from listed packages and their
Requires/Requires.private/Requires.libs/Requires.libs.private packages

Requires.libs.private - Libs.private from listed packages and their
Requires.private/Requires.libs.private packages

This would be analogous to Cflags, Libs and Libs.private, but the
information is collected via the Requires mechanism. The two obvious
reasons why you would want this is if you are using another package's
datatypes or symbols, but not both.

I haven't looked at exactly how this would be implemented, but I think
it could be made to work if I recall the handling of the fields from
the last time I looked at that part of the code.


More information about the pkg-config mailing list