race condition in tests/fp/Makefile

[Peter Maydell]

I've just spotted this issue with tests/fp/Makefile which I think
is causing my tests/vm/netbsd builds to fail:

tests/Makefile.include has some rules that invoke a fresh make
process on tests/fp/Makefile:

tests/fp/%:
        $(MAKE) -C $(dir $@) $(notdir $@)

tests/fp/Makefile has some rules that invoke a fresh make process
in the parent build directory:

BUILD_DIR := $(CURDIR)/../..
$(LIBQEMUUTIL):
        $(MAKE) -C $(BUILD_DIR) libqemuutil.a

$(BUILD_DIR)/config-host.h:
        $(MAKE) -C $(BUILD_DIR) config-host.h

This means that we can end up with two 'make' processes
(the original top level one, and the one invoked by the
rules in tests/fp/Makefile) both trying to build things in
the top level build dir simultaneously. They then step on
each others toes and the build can fail.

In the most usual case where "make" and "make check"
run as separate steps, this doesn't happen, because
libqemuutil.a and config-host.h will both be built by
the "make" step, and then the second make invoked in
"make check" will fairly harmlessly see it has nothing
to do. But the tests/vm scripts all directly run
"make check" without a preceding "make", so they can
hit this.

I guess the best fix here is to move the dependencies
on libqemuutil.a and config-host.h into tests/Makefile.include
(though then you wouldn't be able to stand-alone run
tests/fp/Makefile -- does anybody do that?)

Also, should we change tests/vm to separately invoke
'make' and 'make check' ? I think that doing a single
'make check' is a bit fragile because we don't
really test it and there's no rule that says
"check depends on all" or similar AFAIK.

thanks
-- PMM