On 20/03/21 18:06, Paolo Bonzini wrote:
On 20/03/21 17:47, Jessica Clarke wrote:
Commit 3eacf70bb5a83e4775ad8003cbca63a40f70c8c2 neglected to fix this
for softmmu configs, which pull in migration's use of gnutls.
Signed-off-by: Jessica Clarke
---
migration/meson.build | 2 +-
1 file
On 20/03/21 17:47, Jessica Clarke wrote:
Commit 3eacf70bb5a83e4775ad8003cbca63a40f70c8c2 neglected to fix this
for softmmu configs, which pull in migration's use of gnutls.
Signed-off-by: Jessica Clarke
---
migration/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Commit 3eacf70bb5a83e4775ad8003cbca63a40f70c8c2 neglected to fix this
for softmmu configs, which pull in migration's use of gnutls.
Signed-off-by: Jessica Clarke
---
migration/meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/migration/meson.build
On 08/01/21 20:29, Roman Bolshakov wrote:
Paolo,
I tried to use extract_all_objects() to get all object files directly
but it doesn't work on dependency objects defined via
declare_dependency(). It works only on regular targets (libs and
executables). And as far as I understand the intention to
On Thu, Jan 07, 2021 at 08:41:50PM +0100, Paolo Bonzini wrote:
> Il gio 7 gen 2021, 20:36 Roman Bolshakov ha scritto:
>
> > > No I think that Meson should simply explode link_whole libraries to their
> > > constituent objects. This way duplicates are avoided.
> > >
> >
> > Ok. I've looked
Il gio 7 gen 2021, 20:36 Roman Bolshakov ha scritto:
> > No I think that Meson should simply explode link_whole libraries to their
> > constituent objects. This way duplicates are avoided.
> >
>
> Ok. I've looked through related changes in meson and it flattens object
> files implicitly for
On Thu, Jan 07, 2021 at 07:22:06PM +0100, Paolo Bonzini wrote:
> On 07/01/21 19:18, Roman Bolshakov wrote:
> >
> > > 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
On 07/01/21 19:18, Roman Bolshakov wrote:
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
On Thu, Jan 07, 2021 at 05:23:54PM +0100, Paolo Bonzini wrote:
> 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.
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
On Thu, Jan 07, 2021 at 12:41:40PM +0100, Paolo Bonzini wrote:
> On 05/01/21 15:37, Roman Bolshakov wrote:
> > Does it work if you do:
> >
> > crypto_ss.add(authz, qom)
> > libcrypto = static_library('crypto', crypto_ss.sources() + genh,
> > dependencies:
On 05/01/21 15:37, Roman Bolshakov wrote:
Does it work if you do:
crypto_ss.add(authz, qom)
libcrypto = static_library('crypto', crypto_ss.sources() + genh,
dependencies: crypto_ss.dependencies(),
...)
crypto =
On 05/01/21 15:37, Roman Bolshakov wrote:
Does it work if you do:
crypto_ss.add(authz, qom)
libcrypto = static_library('crypto', crypto_ss.sources() + genh,
dependencies: crypto_ss.dependencies(),
...)
crypto =
On Mon, Jan 04, 2021 at 09:50:32PM +0100, Paolo Bonzini wrote:
> On 04/01/21 18:24, Roman Bolshakov wrote:
> > Hi Paolo,
> >
> > I'm sorry I didn't reply earlier. As I showed in an example to Peter
> > (https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg00085.html):
> >
On 04/01/21 18:24, Roman Bolshakov wrote:
Hi Paolo,
I'm sorry I didn't reply earlier. As I showed in an example to Peter
(https://lists.gnu.org/archive/html/qemu-devel/2021-01/msg00085.html):
https://github.com/mesonbuild/meson/commit/ff5dc65ef841857dd306694dff1fb1cd2bf801e4
The approach
On Mon, 4 Jan 2021 at 17:49, Paolo Bonzini wrote:
> On 04/01/21 16:19, Peter Maydell wrote:
> > Does this work recursively? For instance monitor/qmp-cmds.c
> > needs the gnutls CFLAGS because:
> > * qmp-cmds.c includes ui/vnc.h
> > * ui/vnc.h includes include/crypto/tlssession.h
> > *
On 04/01/21 16:19, Peter Maydell wrote:
On Mon, 4 Jan 2021 at 14:40, Paolo Bonzini wrote:
On 04/01/21 14:21, Peter Maydell wrote:
The rest of QEMU should only ever be using QEMU's TLS abstractions
and not directly be tied to GNUTLS. So ideally the gnutls flags
should only ever be added in
On Sat, Jan 02, 2021 at 08:43:51PM +0100, Paolo Bonzini wrote:
> On 02/01/21 14:25, Peter Maydell wrote:
> > Question to Paolo -- it seems pretty fragile to have to explicitly
> > list "these source files need these extra CFLAGS" in half a dozen
> > meson.build files, because it's pretty
On Mon, 4 Jan 2021 at 14:40, Paolo Bonzini wrote:
>
> On 04/01/21 14:21, Peter Maydell wrote:
> >> The rest of QEMU should only ever be using QEMU's TLS abstractions
> >> and not directly be tied to GNUTLS. So ideally the gnutls flags
> >> should only ever be added in the crypto/meson.build, and
On 04/01/21 14:21, Peter Maydell wrote:
The rest of QEMU should only ever be using QEMU's TLS abstractions
and not directly be tied to GNUTLS. So ideally the gnutls flags
should only ever be added in the crypto/meson.build, and anything
which depends on that should then get the flags indirectly.
On Mon, 4 Jan 2021 at 12:22, Daniel P. Berrangé wrote:
> > Question to Paolo -- it seems pretty fragile to have to explicitly
> > list "these source files need these extra CFLAGS" in half a dozen
> > meson.build files, because it's pretty non-obvious that adding
> > eg '#include "block/nbd.h"' to
On 04/01/21 13:21, Daniel P. Berrangé wrote:
The actual usage of gnutls should be confined to the crypto/ code.
The rest of QEMU should only ever be using QEMU's TLS abstractions
and not directly be tied to GNUTLS. So ideally the gnutls flags
should only ever be added in the crypto/meson.build,
On Sat, Jan 02, 2021 at 01:25:07PM +, Peter Maydell wrote:
> On Sat, 2 Jan 2021 at 12:54, Roman Bolshakov wrote:
> >
> > crypto/tlscreds.h includes GnuTLS headers if CONFIG_GNUTLS is set, but
> > GNUTLS_CFLAGS, that describe include path, are not propagated
> > transitively to all users of
On 02/01/21 14:25, Peter Maydell wrote:
Question to Paolo -- it seems pretty fragile to have to explicitly
list "these source files need these extra CFLAGS" in half a dozen
meson.build files, because it's pretty non-obvious that adding
eg '#include "block/nbd.h"' to a .c file means that you also
On Sat, Jan 02, 2021 at 01:25:07PM +, Peter Maydell wrote:
> On Sat, 2 Jan 2021 at 12:54, Roman Bolshakov wrote:
> >
> > crypto/tlscreds.h includes GnuTLS headers if CONFIG_GNUTLS is set, but
> > GNUTLS_CFLAGS, that describe include path, are not propagated
> > transitively to all users of
On Sat, 2 Jan 2021 at 12:54, Roman Bolshakov wrote:
>
> crypto/tlscreds.h includes GnuTLS headers if CONFIG_GNUTLS is set, but
> GNUTLS_CFLAGS, that describe include path, are not propagated
> transitively to all users of crypto and build fails if GnuTLS headers
> reside in non-standard directory
crypto/tlscreds.h includes GnuTLS headers if CONFIG_GNUTLS is set, but
GNUTLS_CFLAGS, that describe include path, are not propagated
transitively to all users of crypto and build fails if GnuTLS headers
reside in non-standard directory (which is a case for homebrew on Apple
Silicon).
27 matches
Mail list logo
