Artificially target-dependend compiles

[Markus Armbruster <armbru@redhat.com>]

Some .c need to be compiled per target.  build-system.rst calls these
target-dependent.

Consider hw/acpi/vmgenid.c.  hw/acpi/meson.build has

    acpi_ss.add(when: 'CONFIG_ACPI_VMGENID', if_true: files('vmgenid.c'))

and

    softmmu_ss.add_all(when: 'CONFIG_ACPI', if_true: acpi_ss)

softmmu_ss is target-independent, and so is hw/acpi/vmgenid.c.

The C macro CONFIG_ACPI_VMGENID is actually target-dependent;
config-poison.h has

    #pragma GCC poison CONFIG_ACPI_VMGENID

This feels odd until you think about it some.  Meson's
CONFIG_ACPI_VMGENID means "we need to compile hw/acpi/vmgenid.c (because
at least one target we're building needs it)".  We have no use for a C
macro with this meaning.  We sometimes want "*this* target needs it".
That's C macro CONFIG_ACPI_VMGENID.  It's unused, as far as I can tell.
Similar C macros exist that are used.


QMP command query-vm-generation-id exists regardless of either
CONFIG_ACPI_VMGENID.  For targets with CONFIG_ACPI_VMGENID, we link the
real handler from hw/acpi/vmgenid.c.  For other targets, we link the
stub from stubs/vmgenid.c, which always fails.

This works, but it's not introspectable.  To make it introspectable,
we'd have to make the command conditional.  Naive attempt:

    diff --git a/qapi/machine.json b/qapi/machine.json
    index 17794ef681..e554cac53d 100644
    --- a/qapi/machine.json
    +++ b/qapi/machine.json
    @@ -264,7 +264,8 @@
     #
     # Since: 2.9
     ##
    -{ 'struct': 'GuidInfo', 'data': {'guid': 'str'} }
    +{ 'struct': 'GuidInfo', 'data': {'guid': 'str'},
    +  'if': 'CONFIG_ACPI_VMGENID' }

     ##
     # @query-vm-generation-id:
    @@ -273,7 +274,8 @@
     #
     # Since: 2.9
     ##
    -{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo' }
    +{ 'command': 'query-vm-generation-id', 'returns': 'GuidInfo',
    +  'if': 'CONFIG_ACPI_VMGENID' }

     ##
     # @system_reset:

No go, because CONFIG_ACPI_VMGENID can only be used in target-dependent
code.

Moving these definitions to machine-target.json moves the generated C
from qapi/qapi-*-machine.[ch] to qapi/qapi-*-machine-target.[ch], where
CONFIG_ACPI_VMGENID is okay.  It also makes qmp_query_vm_generation_id()
target-dependent: it needs qapi/qapi-commands-machine-target.h.

The target-dependence is completely artificial: compiling
hw/acpi/vmgenid.c just once is as fine as it ever was.

You might challenge the utility of making this one introspectable.  I'm
not going to debate; it's just a random example.  The problem exists
unless you can demonstrate that introspection is useless for *all*
commands with similar target-dependent stubbery.


Have you seen similar artificial target-dependence elsewhere?

Any smart ideas on avoiding it?