[coreboot] r3663 - trunk/coreboot-v2/src/config

svn at coreboot.org svn at coreboot.org
Fri Oct 17 01:44:21 CEST 2008

Author: hailfinger
Date: 2008-10-17 01:44:21 +0200 (Fri, 17 Oct 2008)
New Revision: 3663

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

Extensive comments explain what the workaround does.

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

Modified: trunk/coreboot-v2/src/config/Config.lb
--- trunk/coreboot-v2/src/config/Config.lb	2008-10-16 19:20:51 UTC (rev 3662)
+++ trunk/coreboot-v2/src/config/Config.lb	2008-10-16 23:44:21 UTC (rev 3663)
@@ -162,9 +162,16 @@
 	action	"doxygen corebootDoc.config"
+# 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   
 	depends	"$(TOP)/util/romcc/romcc.c" 
-	action	"$(HOSTCC) -g $(HOSTCFLAGS) $< -o $@"
+	action	"$(HOSTCC) -g $(HOSTCFLAGS) $< -o romcc.tmpfile"
+	action	"mv romcc.tmpfile $@"
 makerule build_opt_tbl   

More information about the coreboot mailing list