Re: Artificially target-dependend compiles

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 11/5/21 14:45, Markus Armbruster wrote:
>> 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.
>
> If I understand correctly, the problem that
> qapi-commands-machine-target.h is target-dependent, because it uses 
> "#ifdef CONFIG_ACPI_VMGENID" around the prototype?

Around the prototype and struct GuidInfo.

> On one hand, the "#ifdef" is unnecessary: the prototype does not
> depend on anything target-specific.  Removing it will avoid the 
> target-dependence.  On the other hand, the "#ifdef" has a defensive
> purpose, in that an unnecessary definition (such as the one currently
> in the stub) will fail due to the implicit definition of 
> qmp_query_vm_generation_id().

Also, it immediately flags uses of qmp_query_vm_generation_id() and
struct GuidInfo.  Without it, the linker still catches most, but not all
uses.

>> Have you seen similar artificial target-dependence elsewhere?
>
> I can't think of a specific example, but it does ring some bells.

I just ran into an instance that may be clearer.

The "rocker" device is target-independent (hw/net/meson.build adds it to
softmmu_ss), but linked only for selected targets (hw/net/Kconfig has
depends on PCI && MSI_NONBROKEN).

This makes our build machinery put CONFIG_ROCKER in
$TARGET-softmmu-config-devices.h, and poison it in config-poison.h.
Feels uncalled for.