Re: [PULL 44/48] meson: Introduce target-specific Kconfig

[Peter Maydell]

On Sat, 17 Jul 2021 at 23:59, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Thu, 8 Jul 2021 at 16:49, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >
> > From: Philippe Mathieu-Daudé <f4bug@amsat.org>
> >
> > Add a target-specific Kconfig. We need the definitions in Kconfig so
> > the minikconf tool can verify they exits. However CONFIG_FOO is only
> > enabled for target foo via the meson.build rules.
> >
> > Two architecture have a particularity, ARM and MIPS. As their
> > translators have been split you can potentially build a plain 32 bit
> > build along with a 64-bit version including the 32-bit subset.
> >
> > Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> > Message-Id: <20210131111316.232778-6-f4bug@amsat.org>
> > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> > Reviewed-by: Thomas Huth <thuth@redhat.com>
> > Message-Id: <20210707131744.26027-2-alex.bennee@linaro.org>
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>
> Hi; this change (commit f4063f9c319e392 in master) seems to have
> resulted in qemu-system-tricore no longer building the
> 'tricore_testboard'. Before this commit:
>
> $ ./build/tricore/qemu-system-tricore -M help
> Supported machines are:
> KIT_AURIX_TC277_TRB  Infineon AURIX TriBoard TC277 (D-Step)
> none                 empty machine
> tricore_testboard    a minimal TriCore board
>
> After this commit, 'tricore_testboard' no longer appears in the list.
> The hw/tricore/meson.build uses "when: 'CONFIG_TRICORE'" to
> compile the source files for the board, so presumably that
> CONFIG switch is no longer being defined ?

This seems to be caused because when "CONFIG_FOO=y" is passed on
the minikconf commandline it doesn't appear in the output (though
it is not ignored entirely, because other config options that
FOO selects do appear in the output). For example from my
meson-logs/meson-log.txt:

Configuring arm-softmmu-config-devices.mak with command
Running command: /usr/bin/python3
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/scripts/minikconf.py
--defconfig arm-softmmu-config-devices.mak
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/x86/meson-private/arm-softmmu-config-devices.mak.d
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/configs/devices/arm-softmmu/default.mak
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/Kconfig CONFIG_TPM=y
CONFIG_SPICE=y CONFIG_IVSHMEM=y CONFIG_OPENGL=y CONFIG_X11=y
CONFIG_VHOST_USER=y CONFIG_VHOST_VDPA=y CONFIG_VHOST_KERNEL=y
CONFIG_VIRTFS=y CONFIG_LINUX=y CONFIG_MULTIPROCESS_ALLOWED=y
CONFIG_TCG=y CONFIG_ARM=y
--- stdout ---
CONFIG_A15MPCORE=y
CONFIG_A9MPCORE=y
[etc]

CONFIG_ARM doesn't apper in the stdout, and so it's not
possible to use it to select something in meson. None
of the other CONFIG_* passed on the commandline appear
in stdout either.

If you look at the aarch64 version:
Running command: /usr/bin/python3
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/scripts/minikconf.py
--defconfig aarch64-softmmu-config-devices.mak
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/x86/meson-private/aarch64-softmmu-config-devices.mak.d
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/configs/devices/aarch64-softmmu/default.mak
/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/Kconfig CONFIG_TPM=y
CONFIG_SPICE=y CONFIG_IVSHMEM=y CONFIG_OPENGL=y CONFIG_X11=y
CONFIG_VHOST_USER=y CONFIG_VHOST_VDPA=y CONFIG_VHOST_KERNEL=y
CONFIG_VIRTFS=y CONFIG_LINUX=y CONFIG_MULTIPROCESS_ALLOWED=y
CONFIG_TCG=y CONFIG_AARCH64=y

CONFIG_AARCH64 doesn't appear in the output, but CONFIG_ARM
does (because AARCH64 selects it).

The only board that gets hit by this is tricore, because as
it happens we don't try to gate anything else on CONFIG_$ARCH.
(Which raises the question of what these CONFIG flags are for
in the first place...)

thanks
-- PMM