Daniel P. Berrangé <berrange@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.maydell@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.
The generated code is used by qemu-ga & storage daemon, at least. They are the first potential consumers, after qemu.
Not sure a subproject would be a good fit.
(I won't repeat the arguments of structuring a project)
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").
Not sure I follow, but that's just the "install" step isn't it ?
Sure, we could have a "qemu-devel", that ships qapi-gen, I guess. But then, you would expect stability/versioning. That's not what I am proposing (at least at this point), which is just about the build system and project structure, so we can build and work on subprojects independently. (for ex, in my wip branch, qemu-ga meson.build is 115 lines, doesn't need QEMU configure etc)
> 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.
I can't see much benefit from doing that extra work. It would create two C APIs, making future bindings efforts more difficult etc.
QObject is very much like GValue though (the naming is better too :), just like the QOM & GObject story.