Rule for libHSghc-8.5-0.a does not exist on Windows

[snowleopard]

After #572, we have yet a new failure on AppVeyor:

Error when running Shake build system:
* _build/stage1/lib/package.conf.d/ghc-8.5.conf
* _build/stage1/compiler/build/libHSghc-8.5-0.a
Error, file does not exist and no rule available:
  _build/stage1/compiler/build/libHSghc-8.5-0.a
CallStack (from HasCallStack):
  error, called at src\Development\Shake\Internal\Rules\File.hs:171:58 in shake-0.16-BDmtKOMxPdtLRnDkDJohXq:Development.Shake.Internal.Rules.File

[snowleopard]

I think this is related to this part of aclocal.m4:

# The version of the GHC package changes every day, since the
# patchlevel is the current date.  We don't want to force
# recompilation of the entire compiler when this happens, so for
# GHC HEAD we omit the patchlevel from the package version number.
#
# The ProjectPatchLevel1 > 20000000 iff GHC HEAD. If it's for a stable
# release like 7.10.1 or for a release candidate such as 7.10.1.20141224
# then we don't omit the patchlevel components.

ProjectVersionMunged="$ProjectVersion"
if test "$ProjectPatchLevel1" -gt 20000000; then
  ProjectVersionMunged="${VERSION_MAJOR}.${VERSION_MINOR}"
fi
AC_SUBST([ProjectVersionMunged])

We need to take care when generating package identifiers. For example, ghc-8.5.20180412 should in fact be replaced with ghc-8.5 to avoid rebuilding the package every day.

[alpmestan]

Curious to see what will happen with https://github.com/snowleopard/hadrian/pull/571, wrt this problem.

[snowleopard]

@alpmestan I think my above idea was incorrect -- this has nothing to do with munged versions. Instead, I'm just hitting some out-of-date piece of code in Hadrian. I think Make build system no longer builds the libHSghc-8.5-0.a library, but Hadrian tries to.

[snowleopard]

This seems to be a relevant commit: https://github.com/ghc/ghc/commit/5266ab9059dffa741b172636f50f1fbfd491dbb4

[snowleopard]

With #574 I finally have a working build on Windows! 🎉