Hi

On Tue, Dec 18, 2018 at 10:27 PM Markus Armbruster <arm...@redhat.com> wrote:
>
> This reverts commit 7bd263490590ee6fcf34ecb6203437e22f6e5a9c.
>
> The commit applied the events' conditions to the members of enum
> QAPIEvent.  Awkward, because it renders QAPIEvent unusable in
> target-independent code as soon as we make an event target-dependent.
> Reverting this has the following effects:
>
> * ui/vnc.c can remain target independent.

Was it ever moved? I don't recall

>
> * monitor_qapi_event_conf[] doesn't have to muck around with #ifdef.

I suggested a way to get rid of monitor_qapi_event_conf[] in the patch
message, by having the rate stored in the schema, which could actually
be useful (for doc, introspection etc).

>
> * query-events again doesn't reflect conditionals.  I'm going to
>   deprecate it in favor of query-qmp-schema.

I guess that's not that important.

I have a slight preference for not declaring enums when the related
option is disabled.

But people don't like having too much #ifdef code, which is understandable.

>
> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>
> # Conflicts:
> #       scripts/qapi/events.py
> ---
>  scripts/qapi/events.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/qapi/events.py b/scripts/qapi/events.py
> index e988e43941..c944ba90b8 100644
> --- a/scripts/qapi/events.py
> +++ b/scripts/qapi/events.py
> @@ -194,7 +194,9 @@ void %(event_emit)s(%(event_enum)s event, QDict *qdict);
>              self._genc.add(gen_event_send(name, arg_type, boxed,
>                                            self._event_enum_name,
>                                            self._event_emit_name))
> -        self._event_enum_members.append(QAPISchemaMember(name, ifcond))
> +        # Note: we generate the enum member regardless of @ifcond, to
> +        # keep the enumeration usable in target-independent code.
> +        self._event_enum_members.append(QAPISchemaMember(name))
>
>
>  def gen_events(schema, output_dir, prefix):
> --
> 2.17.2
>
>


-- 
Marc-André Lureau

Reply via email to