tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: question

On Mon, Apr 15, 2013 at 11:24 AM, Thomas Klausner <> wrote:
On Mon, Apr 15, 2013 at 01:48:55AM +0300, Aleksey Cheusov wrote:
> Suppose we have package A that provides,
> and package B that provides
> Package A depends on B, and is unconditionally linked with
> We also have packages C_1..C_n that depend on A and its
> binaries are linked with (and _possibly_ directly with
> Does this mean that it is always better to add
>   .include "B/"
> to "A/" and remove it from C_i/Makefile ?
> If not, we'll have the same
>   .include "B/"
> in multiple places or build failures if C_i need


If A links against B or uses headers from B in its header files, A's must include B's

I thought about the problem for some time and concluded that this step
depends on how many libraries or headers A provides and how
"popular" libraries linked with B are. If only one library is provided
then A's should include B's and B's should be
removed from Makefiles.

Independent of that:
If C uses B directly, it must include its

Well, in my view this is not needed and even harmful.
Maintainence becomes harder.

So a mix of your answers, I think :)

> Real example:
> A  -- x11/libdrm (
> B  -- sysutils/libpciaccess

So what is to be changed here, if anything?

Nothing in this particular case. The "main" library provided by libdrm is which is not linked with libpciaccess. is used relatively rare. So, I won't change its and will add pciaccess's to apropriate Makefiles.

Initially, I overlooked "multiple libraries/headers" case.

Home | Main Index | Thread Index | Old Index