Re: [PATCH] qapi: Make some ObjectTypes depend on the build settings

[Markus Armbruster <armbru@redhat.com>]

Thomas Huth <thuth@redhat.com> writes:

> On 28/09/2021 19.39, Philippe Mathieu-Daudé wrote:
>> I quickly opened qapi/qom.json and spotted another one:
>> --- a/qapi/qom.json
>> +++ b/qapi/qom.json
>> @@ -870,3 +870,4 @@
>>         'tls-cipher-suites':          'TlsCredsProperties',
>> -      'x-remote-object':            'RemoteObjectProperties'
>> +      'x-remote-object':            { 'type': 'RemoteObjectProperties',
>> +                                      'if': 'CONFIG_MULTIPROCESS' },
>>     } }
>
> No, CONFIG_MULTIPROCESS is in config-poison.h (it's target specific),
> so that won't work here. We can only use the CONFIG switches from
> config-host.h here.

Target-specific conditions are available in qapi/*-target.json only.

The generated qapi-*-target.h are only usable from target-specific
code.

Moving stuff to qapi/*-target.json may necessitate compiling much more
code per target.  Care is advised.

>> While your change is correct, this isn't maintainable long term.
>> Not sure how we could improve that :/ But having to handle similar
>> information in 3 different places (configure, meson.build, qapi json)
>> is error prone. Thoughts?
>
> The current situation is just that bad since we didn't have these
> 'if:' statements in the past. For future code, I think we just have to
> be more careful during code review...

In my opinion, use of CONFIG_FOO in QAPI schemata is no worse than using
them in C type definitions.

In both cases, we have a choice: compile out stuff this build doesn't
need with compile-time conditionals, or leave it in unused.

In C, we sometimes have to compile out stuff, say when it depends on
headers we don't have.

In QAPI, we sometimes want to compile out stuff to make introspection
more useful.  This can be a killer argument.

> (and for configure vs. meson.build the answer is clear: Move more
> stuff from the configure script into meson.build, so that configure
> finally is only a stupid simple wrapper script)
>
>  Thomas