Daniel P. Berrangé <berra...@redhat.com> writes: > On Thu, Aug 11, 2022 at 02:50:01PM +0400, Marc-André Lureau wrote: >> Hi >> >> On Thu, Aug 11, 2022 at 2:22 PM Peter Maydell <peter.mayd...@linaro.org> >> wrote:
[...] >> > As Markus says, your branch ends up moving most of qobject into >> > qemu-common/. We are never going to let that out of QEMU proper, >> > because we are never going to allow ourselves to be tied to API >> > compatibility with it as an external library. So anything that >> > >> >> Why is that? We do it with a lot of dependencies already, with stable APIs. >> >> Furthermore, we don't "have to" be tied to a specific ABI/API, we can >> continue to link statically and compile against a specific version. like >> with libvfio-user today. >> >> And at this point, I am _not_ proposing to have an extra "qemu-common" >> repository. I don't think there are enough reasons to want that either. >> >> >> >> > needs qobject is never going to leave the QEMU codebase. Which >> > means that there's not much gain from shoving it into subproject/ >> > IMHO. >> >> >> (just to be extra clear, it's qobject not QOM we are talking about) >> >> qobject is fundamental to all the QAPI related generated code. Why should >> that remain tight to QEMU proper? > > Neither qobject nor QOM have ever been designed to be public APIs. > Though admittedly qobject is quite a bit simpler as an API, I'm > not convinced its current design is something we want to consider > public. As an example, just last month Markus proposed changing > QDict's implementation > > https://lists.gnu.org/archive/html/qemu-devel/2022-07/msg00758.html > > > If we want external projects to be able to take advantage of QAPI, > the bare minimum we need to be public is a QAPI parser, from which > people can then build any code generators desired. Basically scripts/qapi/ less the code generators. Not sure a subproject would be a good fit. Shot from the hip: could the build process spit out something external projects could consume? It's how "consumables" are commonly delivered. E.g. .so + a bunch of headers. Sometimes that gets packaged. Sometimes it gets copied into the consuming tree ("vendored"). > We don't neccessarily need the current QAPI C code generator. There > could be a new C generator that didn't use qobject, but instead used > some standard GLib types like GHashTable/GList instead of QDict/QList. Yes, that should be possible.
