On 03/02/2020 15.57, Thomas Huth wrote: > On 03/02/2020 15.50, Peter Maydell wrote: >> On Mon, 3 Feb 2020 at 14:30, Thomas Huth <th...@redhat.com> wrote: >>> >>> On 03/02/2020 15.04, Peter Maydell wrote: >>>> On Mon, 3 Feb 2020 at 12:38, Thomas Huth <th...@redhat.com> wrote: >>>>> >>>>> Hi Peter, >>>>> >>>>> the following changes since commit >>>>> 28db64fce555a03b4ca256d5b6f4290abdfbd9e8: >>>>> >>>>> Merge remote-tracking branch >>>>> 'remotes/stefanha/tags/tracing-pull-request' into staging (2020-01-31 >>>>> 17:37:00 +0000) >>>>> >>>>> are available in the Git repository at: >>>>> >>>>> https://gitlab.com/huth/qemu.git tags/pull-request-2020-02-03 >>>>> >>>>> for you to fetch changes up to 585c138628bbf22ea8e740b2f4f1a3ed0274ebe8: >>>>> >>>>> trivial: Remove xenfb_enabled from sysemu.h (2020-02-03 10:33:57 +0100) >>>>> >>>>> ---------------------------------------------------------------- >>>>> * Current qtests queue >>>>> * Some Kconfig updates >>>>> * Some trivial clean-ups here and there >>>>> ---------------------------------------------------------------- >>>> >>>> All the incremental rebuilds failed: >>>> >>>> Linux cam-vm-266 4.15.0-70-generic x86_64 >>>> From git://git-us.linaro.org/people/pmaydell/qemu-arm >>>> f31160c7d1..f9e931a1d9 staging -> pmaydell/staging >>>> make: Entering directory '/home/petmay01/qemu-for-merges/build/w64' >>>> make[1]: Entering directory '/home/petmay01/qemu-for-merges/slirp' >>>> make[1]: Nothing to be done for 'all'. >>>> make[1]: Leaving directory '/home/petmay01/qemu-for-merges/slirp' >>>> CC qga/main.o >>>> CC stubs/machine-init-done.o >>>> CC stubs/replay-user.o >>>> CC stubs/semihost.o >>>> CC qemu-img.o >>>> CC qemu-io.o >>>> CC chardev/char.o >>>> make: *** No rule to make target >>>> '/home/petmay01/qemu-for-merges/hw/bt/Kconfig', needed by >>>> 'aarch64-softmmu/config-devices.mak'. Stop. >>>> make: *** Waiting for unfinished jobs.... >>>> CC chardev/char-mux.o >>>> make: Leaving directory '/home/petmay01/qemu-for-merges/build/w64' >>> >>> Oh, they are still failing??? Why are there still references to >>> hw/bt/Kconfig in these config-devices.mak files, I'd expect that they >>> would have been regenerated at least once during the past week? >> >> build/all/aarch64-softmmu/config-devices.mak.d was most recently >> touched this morning, and it still includes hw/bt/Kconfig in its >> dependency list. I think this is because minikconf will still put >> a Kconfig file into the .d file it generates even if the Kconfig >> file happens to be empty. > > Oh, that's very weird. minikconf should only do that if the file is > included somewhere, but the inclusion of hw/bt/Kconfig has been removed > in 1d4ffe8dc77cbc9aafe8bcf514ca0e43f85aaae3 already, so this really > should not happen anymore...
D'oh, MINIKCONF_INPUTS uses hw/*/Kconfig as wildcard ... that's why it still shows up ... darn, I need to think about how to get rid of this in a nice way... Thomas
