Re: bl3.mk question

On Mon, Apr 15, 2013 at 11:24 AM, Thomas Klausner <wiz%netbsd.org@localhost> wrote:

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

My POV:

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

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 bl3.mk should include B's bl3.mk and B's bl3.mk should be

removed from Makefiles.

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

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 (libdrm_intel.so)
> B -- sysutils/libpciaccess

So what is to be changed here, if anything?

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

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