Re: [PATCH] meson: Propagate gnutls dependency

[Paolo Bonzini]

On 07/01/21 16:56, Roman Bolshakov wrote:
> IMO duplication of dependencies shouldn't be needed for a build system.
> Meta build system should allow private and public dependencies. Different
> rules are applied to them. Private dependency is not propagated beyond a
> target that uses it, public dependency is propagated.
>
> Right now it seems that meson is missing the notion of public and
> private dependencies and that's where the problem arises. The post [1] (and
> the related issue) summarizes what I'm trying to say.

Meson doesn't have a concept of public dependencies because it separates 
the private (static library) and the public (declare_dependency) view. 
That is you'd have:

public_deps = [gnutls, anotherpublicdep]
lib = static_library(..., dependencies: public_deps + [aninternaldep])
dep = declare_dependency(link_with: lib, dependencies: public_deps)

The real issue is that Meson's implementation of link_whole for 
library-in-library makes sense for one use case (convenience library 
that is linked into another convenience library) but not for another 
(grouping code for subsystems).  I cannot blame them for this because 
link_with is a more common case for the latter; OTOH QEMU is using 
link_whole a lot in order to support the *_init() construct.

I really think the correct fix is for Meson to use objects instead of 
archives for link_whole, similar to how QEMU Makefiles used to do it. 
This would also remove the need for the special .fa suffix, so it would 
be an improvement all around.

Paolo

> If we resolve the issue, then we just specify gnutls as a public
> dependency of crypto and all users of crypto would get gnutls headers.
>
> Here's an example how clearly CMake approaches the issue [2][3]:
>
> add_library(crypto OBJECT crypto-file1.c ...)
> target_link_libraries(crypto PRIVATE aninternaldep
>                               PUBLIC  gnutls
>                                       anotherpublicdep)
>
> 1.https://github.com/mesonbuild/meson/issues/495#issuecomment-206178570
> 2.https://cmake.org/cmake/help/latest/command/target_link_libraries.html#linking-object-libraries
> 3.https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents