Hackishly fix parallel build failure with in-tree GMP
authorAustin Seipp <austin@well-typed.com>
Tue, 7 Jan 2014 09:52:38 +0000 (03:52 -0600)
committerAustin Seipp <austin@well-typed.com>
Tue, 7 Jan 2014 09:52:38 +0000 (03:52 -0600)
See the comments and #8102. The basic gist of it seems to be that the
build system follows an implied rule from somewhere to directly build a
C file, which doesn't have a dependency on the in-tree gmp.h that we
build. As a result, the C file compilation races against the GMP build,
causing an error.

This is a pretty unsatisfactory hack, but for Windows and OS X machines
where we more often build in-tree GMPs, it's quite important.

Authored-by: Kazu Yamamoto <kazu@iij.ad.jp>
Signed-off-by: Austin Seipp <austin@well-typed.com>
mkGmpDerivedConstants/ghc.mk

index 6c06224..1729b1a 100644 (file)
@@ -26,7 +26,14 @@ $(GmpDerivedConstants_HEADER): $(mkGmpDerivedConstants_INPLACE)
 
 ifneq "$(HaveLibGmp)" "YES"
 ifneq "$(HaveFrameworkGMP)" "YES"
-$(libraries/integer-gmp/mkGmpDerivedConstants_dist_depfile_c_asm): libraries/integer-gmp/gmp/gmp.h
+# NOTE: we should really be referring to the depfile generated by the build
+# system here, but due to an awkward contortion I can't figure out, the build
+# system follows an implied from somewhere else to directly build the C file
+# instead (independent of the depfile rules), which doesn't have a built gmp.h
+# dependency. This race causes the parallel build to fail.
+#
+# See #8102
+libraries/integer-gmp/mkGmpDerivedConstants/mkGmpDerivedConstants.c: libraries/integer-gmp/gmp/gmp.h
 endif
 endif