On 5/13/25 12:08 AM, Markus Armbruster wrote:
Pierrick Bouvier <pierrick.bouv...@linaro.org> writes:
On 5/9/25 11:57 PM, Markus Armbruster wrote:
The build system would need generate an input document for the
QAPI visitor that defines whether each constant is set to true
or false, based on suitable CONFIG/TARGET conditions from meson.
I think the conditions that are evaluated at build time in handwritten C
code (with #if) should also be evaluated at build time in generated C
code.
Certain conditions are evaluated at build time in target-specific code,
and at runtime in target-independent code. Again, I think handwritten
and generated code should work the same way.
Thus, to eliminate target-specific QAPI-generated code, we either
evaluate them at runtime, or simply eliminate them. Elsewhere, we've
come to the conclusion (I think) that the latter should do at least for
now, likely forever, so we should try that first.
I'm not sure if you mean you'd prefer to eradicate #if completely.
I do not!
We have to keep in mind that some config host #if have to stay there, or
they expose things that the rest of QEMU code is not supposed to see
(hidden under those same CONFIG_ ifdef also).
Letting people configure their QEMU build is useful and must stay.
We provide this via conditional compilation, of complete source files
(done in meson), as well as within source files (#if in C and 'if' in
QAPI).
So we would need both if and runtime_if.
I don't understand the need for runtime_if. Can you give an example?
That is the point of this whole series, which explores introducing a
'runtime' if in the schema, to keep it as it is today, while removing
target specific compile time defines.
It is another approach that one Daniel followed on his series.
I invite you to give a quick read to this series, especially the related
commit introducing 'runtime_if'
(20250507231442.879619-2-pierrick.bouv...@linaro.org).
As well, I would appreciate if you could state clearly where we are
going with all this (or at least, where you *don't* want this to go), so
we can avoid spending time in the wrong direction.
I am ok to pursue Daniel's approach, or continue the approach in the
current series, no strong opinion in my side, I am just trying to move
QAPI generated code out of the way for the single binary goal.
Thanks,
Pierrick
