[Top][All Lists]

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

Re: Artificially target-dependend compiles

From: Thomas Huth
Subject: Re: Artificially target-dependend compiles
Date: Mon, 8 Nov 2021 16:38:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0

On 08/11/2021 09.09, Markus Armbruster wrote:
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.

Hmm, we used to have a config-all-devices.mak file in the past (see commit a98006bc798169e which removed it), maybe we could re-introduce something similar again, but producing a config-all.h header file instead? So that this header file contains switches like CONFIG_ANY_ACPI_VMGENID and CONFIG_ANY_ROCKER that are set if any of the targets uses the device ... and these switches would not get poisoned in common code... ?


reply via email to

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