Re: Artificially target-dependend compiles

[Markus Armbruster <armbru@redhat.com>]

Markus Armbruster <armbru@redhat.com> writes:

[...]

> 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.

Hmm, maybe not.

Our build process links the rocker stuff for selected targets.

The QAPI schema provides rocker definitions unconditionally.
QAPI-generated rocker code gets linked for all targets.  The
command handlers resolve to the real ones when on the selected targets,
else to stubs.

This works and is fairly simple.  We link a bit of useless code
(QAPI-generated and stubs).  query-qmp-schema can't tell us whether
rocker is present, which is sad, but there's a work-around:
qom-list-types.

We may still run into cases where we really want query-qmp-schema to
tell, say because there is no easy work-around.

Making the QAPI schema definitions properly conditional does the trick,
but makes code artificially target-dependent, slowing down the build.
It can also lead to extra #ifdeffery, because now useless code doesn't
compile anymore.

Simply not poisoning the CONFIG_FOO when the FOO code is actually
target-independent avoids the target-dependency, but also messes up
introspection: new the FOO stuff is present for all targets when *any*
of them has it.  This cure feels worse than the disease.

Needs more thought.