Daniel P. Berrangé <berra...@redhat.com> writes:
> This allows us to include multiple QAPI schemas in the same file.
>
> Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
This commit prepends an optional prefix to generated uses of
QAPI_FEATURE_{DEPRECATED,UNSTABLE}.
It touches neither the handwritten definition in include/qapi/util.h,
nor the handwritten uses in qapi/qapi-util.c and
qapi/qobject-output-visitor.c.
Code generated with a prefix will not compile, unless it uses no
features. No biggie, because:
The next commit replaces the handwritten definition (no prefix) by a
generated one (with optional prefix).
Now the handwritten code compiles only because it includes an enum
definition generated without a prefix, namely the main schema's.
Note that the handwritten code continues to work even when you use it
together with some other schema, but only because all the generated
enums assign the same numeric value to the enumeration constants
_DEPRECATED and _UNSTABLE.
While that seems fairly unlikely to break accidentally, it still feels
unnecessarily dirty.
What about generating an enum like this:
typedef enum {
QAPI_FEATURE_DEPRECATED = QAPI_DEPRECATED,
QAPI_FEATURE_UNSTABLE = QAPI_UNSTABLE,
...
} QapiFeature;
where QAPI_DEPRECATED and QAPI_UNSTABLE are defined in qapi/util.h, like
they are before this series.
We can discuss renaming them to QAPI_SPECIAL_FEATURE_DEPRECATED and
_UNSTABLE if you like.
Code referring to special features, i.e. all references before this
series, use the definitions from qapi/util.h.
Code referring to arbitrary, possibly non-special features, i.e. the
references new in this series, use the generated definitions from
qapi/qapi-features.h.
Thoughts?
