> - placing pkg-config output directly in $(QEMU_CFLAGS) and $(LIBS).
> This caused binaries to have unnecessary dependencies at times.
Yeah, this is what I think of as "the standard thing".
Got it, and it wasn't exactly what QEMU was doing. There was at least libs_softmmu, libs_qga. So in practice it would be more similar to the other one:
> - a mix of the two, with the include path added to QEMU_CFLAGS and a
> target variable definition "foo$(EXESUF): LIBS += ..." that avoided the
> unnecessary dependencies.
which meson does support.
However the issue you mention below is indeed the gnutls bug, and it can be fixed. If I recall correctly it was meant to be a temporary workaround for the actual bug.
I need to check again but I recall I had two fixes in mind, one was a more risky change in Meson, the other was a new declare_dependency(..., objects: ...) argument to be used instead of link_whole. link_whole was used before but it didn't work for some reason, maybe something to do with static linking.
I was hoping to stop the Meson upgrades at 0.63, but I agree that it is messy and it would be a good reason for another bump in the future.
Paolo
The thing I find counterintuitive about what we have currently
is that I can add a #include of a QEMU-internal header to a
source file, and now the build can be broken on some host
system configurations.
Paolo
I'd be happier with either:
(1) it's always safe to #include QEMU's own headers in its
source files
(2) sometimes a new QEMU header #include requires you to add a
dependency to a meson.build file, but if you forget to do
this then the build reliably fails on *all* host systems
thanks
-- PMM