[Qemu-devel] Makefile bug: %/config-devices.mak doesn't depend on .mak files included by defconfig

[Peter Maydell]

I recently ran into a confusing stale-file issue when adding a new
device to an ARM board: when doing a make not from clean after
having switched from master to my branch the .o file for the new
device got linked into the arm-softmmu exe but not the aarch64-softmmu
one. This turns out to be an issue in our makefile:

For each target (arm-softmmu, aarch64-softmmu, etc) a file is
created in the build tree $(target)/config-devices.mak, which is a bunch
of CONFIG_THINGY=y statements and gets included in the makefile
so we know which common object files need to be linked in.
There is a dependency rule used to update this .mak file, which is
%/config-devices.mak: default-configs/%.mak

So if you edit default-configs/arm-softmmu.mak, say to add
"CONFIG_NEWDEVICE=y", then we rebuild the
arm-softmmu/config-devices.mak file and the result is that the obj-y
line for the target correctly includes the newdevice .o files and they end
up in the link line for the executable.

However, that dependency rule does *not* take any notice of
files which the default-configs file merely includes; so if you edit
a default-configs/foo.mak which is included by some target's
default-configs file (pci.mak is one that's included by a bunch of
targets) then that change in the source tree does not trigger a
rebuild of config-devices.mak, and the compile will proceed fine
but without the set of devices changing.

In particular, aarch64-softmmu's defconfig just includes
the arm-softmmu one. So changes to the arm-softmmu defconfig
result in an update for the arm-softmmu/config-devices.mak
but not for aarch64-softmmu/config-devices.mak, and the
new device gets linked into one exe but not the other...

A distclean will work around this, of course, but given the
existence of common config files like pci.mak and usb.mak
it would be nice if the makefile could handle the includes
when figuring out the dependency line for config-devices.mak...

thanks
-- PMM