|Subject:||incorrect handling of error codes with -j flag|
|Date:||Thu, 30 May 2019 09:06:13 +0000|
We have identified a situation where make will randomly return 2 or 0 for the same recipe.
Our build system compiles unit tests, runs the unit test executable and then performs some basic clean-up after the test is run.
We have something like this:
$(derived_dir)/app /unit_tests/%_tests.pass: \
$(AT)$(call PTCOMPILECPP,$(TEMP)/app -$(subst /,-,$*)_tests$(PTOBJEXT),app_orion_picasso_resources/unit_tests/$*_tests.cpp)
$(AT)$(call PTRUN,$(TEMP)/app-$(subst /,-,$*)$(PTEXT)) $(programmer_test_flags)
$(AT)$(PYTHON) $(MAKEROOT)/rm.py $(TEMP)/app-$(subst /,-,$*)$(PTEXT) $(TEMP)/app-$(subst /,-,$*)_tests$(PTOBJEXT) $(TEMP)/app-$(subst /,-,$*)$(PTOBJEXT)
$(AT)$(PYTHON) $(MAKEROOT)/rm.py -f $(TEMP)/app-$(subst /,-,$*).pdb
$(AT)$(PYTHON) $(MAKEROOT)/touch.py $@
We execute rm.py and touch.py instead of Linux commands to handle porting issues for Windows and Linux, but the basics are the unit test will be deleted when the test passes, or be left in the file system if the test fails.
The unit test executable will return error code 2 when it fails, then make returns 0 or 2 when a unit test fails.
We tested this with -j8 and can see the return code is randomly returned as 0 or 2 each time we compile and run the test, but with -j1 make will always return 0.
We fixed the problem by placing – in front of the rm.py and touch.py commands, but it seems there is some sort of multi-process issue here, and I would still expect 0 to always be returned with this problem in the makefile.
We would also expect these lines to be treated as sequential in a single process, but is that actually happening?
We are also using the gnu make build on Windows, and the behaviour is consistently behaving the same for -j1 and -j8, so it appears to only be a problem for Linux.
|[Prev in Thread]||Current Thread||[Next in Thread]|