[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Artificially target-dependend compiles

From: Markus Armbruster
Subject: Re: Artificially target-dependend compiles
Date: Mon, 08 Nov 2021 09:09:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

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:

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]