Il ven 9 dic 2022, 20:54 Peter Maydell <peter.mayd...@linaro.org> ha scritto:
> > - 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 > >
