From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Emilio G. Cota" <cota@braap.org>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: race condition in tests/fp/Makefile
Date: Tue, 07 Jan 2020 17:04:10 +0000 [thread overview]
Message-ID: <87imlnjj05.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA-U1JqzH8m2AWV7KuJKm0WfczDKK+ddzPs44y9usujB2Q@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> 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
next prev parent reply other threads:[~2020-01-07 17:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-07 16:08 race condition in tests/fp/Makefile Peter Maydell
2020-01-07 17:04 ` Alex Bennée [this message]
2020-01-07 17:06 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87imlnjj05.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=cota@braap.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).