[Top][All Lists]

[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)/../..
>         $(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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]