Building ghc on Windows with msys2

[Herbert Valerio Riedel]

On 2014-10-08 at 04:28:50 +0200, cg wrote:

[...]

> After cloning ghc repository, I switch every sub-module to Master (it is
> usually HEAD) branch.

Why are you doing that? :-)

[...]

> Now after cloning ghc repository, if I don't switch to any branch -- 
> 'git branch'
> will show all submodules are detached -- the build will succeed.

Well, that's how you're supposed to work with submodules in ghc.git[1]

> So why the Master/HEAD branches don't have the latest code?

Generally, the "master" branch refers to the latest upstream code,
which is not always supposed to work with GHC HEAD (yet). And if the
package is not owned by GHC HQ, you are not allowed to push changes to
"master" anyway (as it'd be automatically overwritten by the automatic
Git mirror job)

Take Cabal for example, we have an automatic mirror-job that keeps
Cabal's "master" branch synced to the state of the github.com/

However, we only update the gitlink for Cabal in ghc.git every couple of
weeks to Cabal's latest "master" tip commit, as it has the potential to
affect performance numbers or simply be temporarily in a broken state
wrt GHC HEAD.


Then there's Haddock for which it was recently decided to let upstream
development progress decoupled from GHC HEAD's API changes, and have GHC
HEAD simply use its own branch 'ghc-head' to diverge from upstream until
shortly before a GHC release is close (at which point Haddock will
converge again). Fwiw, 'git submodule update --remote utils/haddock'
will track the "ghc-head" branch in this case.


Finally, "binary" is a case where we needed a patch merged into binary,
but couldn't wait for the "binary" upstream to merge the pull-request,
as it was blocking GHC HEAD development. So that's why we temporarily
are on a "ghc-head" branch, which will be switched away from again as
soon as "binary"'s upstream "master" branch can be used again with GHC
HEAD.


And then there's also the potential case when we need to temporarily
rollback a submodule update; then we don't necessarily need to 'git
revert' commits inside that submodule, but we simply just reset the
pointed-to submodule commit to an older commit.


I hope this sheds a bit of light on the situation. Then there's also [1]
which may provide further pointers.


 [1]: https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules

Cheers,
  hvr