Synchronise ghci-package version with ghc-package

In order to simplify the task, the version munging logic has
been radically simplified:

Previously, in cases where the version contained dates as version components,
the build-system would munge the version of the stage1 ghc package before
registering the `ghc` package.

However, this hack was already questionable at the time of its introduction
(c.f. 7b45c46cbabe1288ea87bd9b94c57e010ed17e60).
Simplifying the build-systems by avoiding such hacks may also help the
shaking-up-ghc effort.

So now we simply munge directly via the `.cabal` files, which gives a simpler
picture, as now every stage is munged the same. Munging is only active when
the first patch-level version component is a date. So stable snapshots and release
candidates are unaffacted (as those have the date in the second patch-level
version component)

Reviewers: simonmar, bgamari, austin, thomie, ezyang

Reviewed By: bgamari, thomie, ezyang

Differential Revision: https://phabricator.haskell.org/D1673

1 files changed, 0 insertions, 9 deletions

diff --git a/ghc/ghc.mk b/ghc/ghc.mk
index f8c6b09e3f..c0c78bdef6 100644
--- a/ghc/ghc.mk
+++ b/ghc/ghc.mk
@@ -22,15 +22,6 @@ ghc_stage2_CONFIGURE_OPTS += --flags=ghci
 ghc_stage3_CONFIGURE_OPTS += --flags=ghci
 endif
 
-ifeq "$(compiler_stage1_VERSION_MUNGED)" "YES"
-# If we munge the stage1 version, and we're using a devel snapshot for
-# stage0, then stage1 may actually have an earlier version than stage0
-# (e.g. boot with ghc-7.5.20120316, building ghc-7.5). We therefore
-# need to tell Cabal to use version 7.5 of the ghc package when building
-# in ghc/stage1
-ghc_stage1_CONFIGURE_OPTS += --constraint "ghc == $(compiler_stage1_MUNGED_VERSION)"
-endif
-
 # This package doesn't pass the Cabal checks because data-dir
 # points outside the source directory. This isn't a real problem, so
 # we just skip the check.