GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Revision 3564 improved compilation time, but it also introduced a 

dependency bug which hit people running parallel make instances.

With our current makefile architecture, the "right" fix is impossible.
However, we can still kill the race conditions leading to arbitrary
compilation failures. That trick depends on the atomicity of the mv
command.

Extensive comments explain what the workaround does.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>


git-svn-id: svn://svn.coreboot.org/coreboot/trunk@3663 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This commit is contained in:
Carl-Daniel Hailfinger 2008-10-16 23:44:21 +00:00
parent 4727c07446
commit 8a3ad59653
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
src/config/Config.lb
View File

@ -162,9 +162,16 @@ makerule documentation
action "doxygen corebootDoc.config" action "doxygen corebootDoc.config"
end end
# Yes, the rule doesn't seem to make sense, but multiple images could try to
# create a romcc binary at the same time, clobbering each other.
# Our makefile architecture won't allow us to easily have the romcc target
# in the main makefile, so keep it here and move the race condition winner
# in place. That way, romcc may get compiled twice, but the binary will always
# be in a correct and valid state if it exists because the move is atomic.
makerule ../romcc makerule ../romcc
depends "$(TOP)/util/romcc/romcc.c" depends "$(TOP)/util/romcc/romcc.c"
action "$(HOSTCC) -g $(HOSTCFLAGS) $< -o $@" action "$(HOSTCC) -g $(HOSTCFLAGS) $< -o romcc.tmpfile"
action "mv romcc.tmpfile $@"
end end
makerule build_opt_tbl makerule build_opt_tbl