[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: race condition in tests/fp/Makefile
From: |
Alex Bennée |
Subject: |
Re: race condition in tests/fp/Makefile |
Date: |
Tue, 07 Jan 2020 17:04:10 +0000 |
User-agent: |
mu4e 1.3.6; emacs 28.0.50 |
Peter Maydell <address@hidden> writes:
> 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?)
Not really - it needs bits to build. I guess when testing you might
invoke directly in the tree. I'll make it error out if the parent build
bits aren't there.
> 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.
OK - although shouldn't our rules be robust enough for this.
>
> thanks
> -- PMM
--
Alex Bennée