Re: [RFC PATCH 0/3] single-binary: make QAPI generated files common

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, May 07, 2025 at 09:55:13AM +0200, Markus Armbruster wrote:
> Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:
> 
> [...]
> 
> > I don't think we should think too much ahead for languages other than C, 
> > for one, two, and even three reasons :)
> 
> I agree that thinking ahead too much is a bad habit.  So is thinking
> ahead too little :)
> 
> > - First, it's already broken because we rely on ifdef that won't be 
> > there in Rust or Go.
> 
> I don't think it's broken.  QAPI 'if' translates straightforwardly to C
> #if, but that doesn't mean it cannot be translated to conditional
> compilation / metaprogramming in other languages.
> 
> In fact, the value of 'if' used to be C constant expressions suitable
> for use with #if, and we changed it to its current form specifically to
> enable Rust work, in merge commit c83fcfaf8a5.  Marc-André's was trying
> to develop Rust bindings back then, and if I remember correctly this
> change was enough to let him implement 'if' with Rust.

The usefulness of the conditions to non-C languages may well
vary depended on intended use case.

If I'm writing a mgmt app that can talk to QEMU, and I want
to be able to talk to both x86 and s390 system emulators,
I am unlikely to want the language bindings to omit features
based on TARGET_xxx conditions. I won't want a separate API
for each QEMU arch target, I'll want one API for all arches.

Expanding this further, if I'm writing a mgmt app to talk
to QEMU 9.2.0, I am also unlikely to want the language
bindings to omit features based on CONFIG_xxxx conditions,
because I likely want to talk to a QEMU 9.2.0 built by any
OS distro, each of which may have chosen a different set
of --enable flags for configure, and thus having different
CONFIG_xxx conditions.

TL;DR: in terms of code generation, the prime use case for
conditionally generated code is for QEMU's own internal usage.
For QMP bindings generated for 3rd party app usage, the use
of conditions in generation feels like a niche requirment at
best.

IMHO the code for any public facing API derived from QMP
schema should be invariant for any given QEMU release.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|