mbox

[PULL,00/13] qtests, kconfig and misc patches

Message ID 20200203123811.8651-1-thuth@redhat.com (mailing list archive)
State New, archived
Headers show

Pull-request

https://gitlab.com/huth/qemu.git tags/pull-request-2020-02-03

Message

Thomas Huth Feb. 3, 2020, 12:37 p.m. UTC
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
----------------------------------------------------------------

Dr. David Alan Gilbert (1):
      tests/vhost-user-bridge: Fix build

Heyi Guo (1):
      tests/qtest: update comments about bios-tables-test-allowed-diff.h

Miroslav Rezanina (1):
      test-logging: Fix -Werror=maybe-uninitialized warning

Pan Nengyuan (1):
      boot-order-test: fix memleaks in boot-order-test

Philippe Mathieu-Daudé (1):
      hw/hppa/Kconfig: LASI chipset requires PARALLEL port

Thomas Huth (8):
      docs/devel: Fix qtest paths and info about check-block in testing.rst
      tests/Makefile: Fix inclusion of the qos dependency files
      gitlab-ci: Refresh the list of iotests
      hw/bt: Remove empty Kconfig file
      hw/input: Do not enable CONFIG_PCKBD by default
      hw/*/Makefile.objs: Move many .o files to common-objs
      include/sysemu/sysemu.h: Remove usused variable no_quit
      trivial: Remove xenfb_enabled from sysemu.h

 .gitlab-ci.yml                 | 12 ++++++------
 docs/devel/testing.rst         | 23 ++++++++++++-----------
 hw/adc/Makefile.objs           |  2 +-
 hw/block/Makefile.objs         |  2 +-
 hw/bt/Kconfig                  |  0
 hw/char/Makefile.objs          | 16 ++++++++--------
 hw/core/Makefile.objs          |  2 +-
 hw/display/Makefile.objs       |  2 +-
 hw/dma/Makefile.objs           |  6 +++---
 hw/gpio/Makefile.objs          | 10 +++++-----
 hw/hppa/Kconfig                |  1 +
 hw/i2c/Makefile.objs           |  4 ++--
 hw/i2c/ppc4xx_i2c.c            |  1 -
 hw/input/Kconfig               |  1 -
 hw/input/Makefile.objs         |  8 ++++----
 hw/isa/Kconfig                 |  1 +
 hw/net/Makefile.objs           |  6 +++---
 hw/nvram/Makefile.objs         |  2 +-
 hw/pcmcia/Makefile.objs        |  2 +-
 hw/sd/Makefile.objs            | 10 +++++-----
 hw/ssi/Makefile.objs           |  4 ++--
 hw/usb/Makefile.objs           |  4 ++--
 hw/xenpv/xen_machine_pv.c      |  2 +-
 include/sysemu/sysemu.h        |  2 --
 tests/Makefile.include         |  3 ++-
 tests/qtest/Makefile.include   |  1 -
 tests/qtest/bios-tables-test.c | 10 +++++-----
 tests/qtest/boot-order-test.c  |  6 +++---
 tests/qtest/libqos/fw_cfg.h    |  2 ++
 tests/test-logging.c           |  6 +++---
 30 files changed, 76 insertions(+), 75 deletions(-)
 delete mode 100644 hw/bt/Kconfig

Comments

Peter Maydell Feb. 3, 2020, 2:04 p.m. UTC | #1
On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@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'

thanks
-- PMM
Thomas Huth Feb. 3, 2020, 2:30 p.m. UTC | #2
On 03/02/2020 15.04, Peter Maydell wrote:
> On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@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?

 Thomas
Thomas Huth Feb. 3, 2020, 2:43 p.m. UTC | #3
On 03/02/2020 15.30, Thomas Huth wrote:
> On 03/02/2020 15.04, Peter Maydell wrote:
>> On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@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?

What timestamp do the */config-devices.mak files have on your system?

Could you please also execute a "grep -r bt/Kconfig *" to see whether
there is still anything else stale around?

 Thomas
Peter Maydell Feb. 3, 2020, 2:50 p.m. UTC | #4
On Mon, 3 Feb 2020 at 14:30, Thomas Huth <thuth@redhat.com> wrote:
>
> On 03/02/2020 15.04, Peter Maydell wrote:
> > On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@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.

And make doesn't have any rules that tell it that config-devices.mak.d
need to be updated either:
$ make -C build/all -n aarch64-softmmu/config-devices.mak.d
make: Entering directory '/home/petmay01/linaro/qemu-for-merges/build/all'
make[1]: Entering directory '/home/petmay01/linaro/qemu-for-merges/slirp'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/petmay01/linaro/qemu-for-merges/slirp'
make: Nothing to be done for 'aarch64-softmmu/config-devices.mak.d'.
make: Leaving directory '/home/petmay01/linaro/qemu-for-merges/build/all'

or that it needs to rerun minikconf, which would update the .mak.d.

An extremely cheesy workaround would be if the commit which
removes the hw/bt/Kconfig also touches configure; then Make
will know it needs to rerun configure, which will (among
other things) blow away all the config-devices.mak.d and
force rerunning of minikconf.

I don't know what the correct additional makefile magic
would be that would cause us to automatically get deletion
of a Kconfig file right; maybe Paolo does?

thanks
-- PMM
Thomas Huth Feb. 3, 2020, 2:57 p.m. UTC | #5
On 03/02/2020 15.50, Peter Maydell wrote:
> On Mon, 3 Feb 2020 at 14:30, Thomas Huth <thuth@redhat.com> wrote:
>>
>> On 03/02/2020 15.04, Peter Maydell wrote:
>>> On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@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...

 Thomas
Thomas Huth Feb. 3, 2020, 3:02 p.m. UTC | #6
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 <thuth@redhat.com> wrote:
>>>
>>> On 03/02/2020 15.04, Peter Maydell wrote:
>>>> On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@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
Paolo Bonzini Feb. 3, 2020, 3:17 p.m. UTC | #7
On 03/02/20 15:50, Peter Maydell wrote:
> 
> An extremely cheesy workaround would be if the commit which
> removes the hw/bt/Kconfig also touches configure; then Make
> will know it needs to rerun configure, which will (among
> other things) blow away all the config-devices.mak.d and
> force rerunning of minikconf.
> 
> I don't know what the correct additional makefile magic
> would be that would cause us to automatically get deletion
> of a Kconfig file right; maybe Paolo does?

Nope, sorry. :(

Paolo
Paolo Bonzini Feb. 3, 2020, 3:29 p.m. UTC | #8
On 03/02/20 16:17, Paolo Bonzini wrote:
> On 03/02/20 15:50, Peter Maydell wrote:
>>
>> An extremely cheesy workaround would be if the commit which
>> removes the hw/bt/Kconfig also touches configure; then Make
>> will know it needs to rerun configure, which will (among
>> other things) blow away all the config-devices.mak.d and
>> force rerunning of minikconf.
>>
>> I don't know what the correct additional makefile magic
>> would be that would cause us to automatically get deletion
>> of a Kconfig file right; maybe Paolo does?
> 
> Nope, sorry. :(

Wait, hw/*/Kconfig should not have to be added to minikconf.py's
arguments.  There are "source" lines in hw/Kconfig to do so.  It does
not fail because minikconf skips multiple includes of the same file, but
it should be possible to remove it.

Paolo
Daniel P. Berrangé Feb. 3, 2020, 3:35 p.m. UTC | #9
On Mon, Feb 03, 2020 at 02:50:07PM +0000, Peter Maydell wrote:
> On Mon, 3 Feb 2020 at 14:30, Thomas Huth <thuth@redhat.com> wrote:
> >
> > On 03/02/2020 15.04, Peter Maydell wrote:
> > > On Mon, 3 Feb 2020 at 12:38, Thomas Huth <thuth@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.
> 
> And make doesn't have any rules that tell it that config-devices.mak.d
> need to be updated either:
> $ make -C build/all -n aarch64-softmmu/config-devices.mak.d
> make: Entering directory '/home/petmay01/linaro/qemu-for-merges/build/all'
> make[1]: Entering directory '/home/petmay01/linaro/qemu-for-merges/slirp'
> make[1]: Nothing to be done for 'all'.
> make[1]: Leaving directory '/home/petmay01/linaro/qemu-for-merges/slirp'
> make: Nothing to be done for 'aarch64-softmmu/config-devices.mak.d'.
> make: Leaving directory '/home/petmay01/linaro/qemu-for-merges/build/all'
> 
> or that it needs to rerun minikconf, which would update the .mak.d.
> 
> An extremely cheesy workaround would be if the commit which
> removes the hw/bt/Kconfig also touches configure; then Make
> will know it needs to rerun configure, which will (among
> other things) blow away all the config-devices.mak.d and
> force rerunning of minikconf.
> 
> I don't know what the correct additional makefile magic
> would be that would cause us to automatically get deletion
> of a Kconfig file right; maybe Paolo does?

I guess this would need some munging of config-host.mak rule in the
Makefile. config-host.mak would need to depend on something which
scan for references to deleted Kconfig files, and then forces a re-run
of config.status in some manner. Don't know how we'd write such a
beast off hand though.


Regards,
Daniel
Thomas Huth Feb. 3, 2020, 3:38 p.m. UTC | #10
On 03/02/2020 16.29, Paolo Bonzini wrote:
> On 03/02/20 16:17, Paolo Bonzini wrote:
>> On 03/02/20 15:50, Peter Maydell wrote:
>>>
>>> An extremely cheesy workaround would be if the commit which
>>> removes the hw/bt/Kconfig also touches configure; then Make
>>> will know it needs to rerun configure, which will (among
>>> other things) blow away all the config-devices.mak.d and
>>> force rerunning of minikconf.
>>>
>>> I don't know what the correct additional makefile magic
>>> would be that would cause us to automatically get deletion
>>> of a Kconfig file right; maybe Paolo does?
>>
>> Nope, sorry. :(
> 
> Wait, hw/*/Kconfig should not have to be added to minikconf.py's
> arguments.  There are "source" lines in hw/Kconfig to do so.  It does
> not fail because minikconf skips multiple includes of the same file, but
> it should be possible to remove it.

Right, I came to the same conclusion. Patch is on the way...

 Thomas