On Sat, 17 Jul 2021 at 23:59, Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Thu, 8 Jul 2021 at 16:49, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > > From: Philippe Mathieu-Daudé <f4...@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é <f4...@amsat.org> > > Message-Id: <20210131111316.232778-6-f4...@amsat.org> > > Signed-off-by: Alex Bennée <alex.ben...@linaro.org> > > Reviewed-by: Thomas Huth <th...@redhat.com> > > Message-Id: <20210707131744.26027-2-alex.ben...@linaro.org> > > Signed-off-by: Paolo Bonzini <pbonz...@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
