How do I build GHC 7.6 from source?

[Simon Marlow]

On 20/09/2012 16:25, Iavor Diatchki wrote:
> perhaps we should have a well-defined place in the repo where we keep
> the finger-prints associated with tags and branches in the main repo?
> This would make it a lot easier to get to a fully defined
> previous/different state.

We do have tags for releases, so you can say

  ./sync-all checkout ghc-7.6.1-release

and get the exact 7.6.1 sources.

I wouldn't object to also having fingerprints in the repo too though.

Cheers,
	Simon



> On this note, could someone send the link to the 7.6 fingerprint?  Ian
> said that it is somewhere in the nightly build logs but I don't where to
> look.
>
> -Iavor
>
>
>
> On Thu, Sep 20, 2012 at 7:20 AM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
>
>     On 19/09/2012 02:15, Iavor Diatchki wrote:
>
>            > exactly what git's submodule machinery does, so it seems
>         pointless to
>
>               > implement the functionality which is already there with
>         a standard
>               > interface.  Thoughts?
>
>         http://hackage.haskell.org/__trac/ghc/wiki/DarcsConversion#__Theperspectiveonsubmodules
>         <http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Theperspectiveonsubmodules>
>
>
>         I have seen this.  Our custom "fingerprint" solution has the
>         exact same
>         drawbacks (because it does the exact same thing as sub-modules),
>         and in
>         addition it has the drawback of
>             1. being a custom non-standard solution,
>             2. it is not obvious where to find the "fingerprint"
>         associated with
>         a particular branch (which is what lead to my question in the
>         first place).
>
>
>
>     Well, it doesn't quite have the same drawbacks as submodules,
>     because our solution places a burden only on someone who wants to
>     recover a particular repository state, rather than on everyone doing
>     development.
>
>     I think it's worth keeping an eye on submodules in case they fix the
>     gotchas in the UI, but at the moment it looks like we'd have a lot
>     of confused developers, lost work and accidental breakages due to
>     people not understanding how submodules work or forgetting to jump
>     through the correct hoops.
>
>     I'm not saying fingerprints are a good solution, obviously they only
>     solve a part of the problem, but the current tooling for submodules
>     leaves a lot to be desired.
>
>     Cheers,
>              Simon
>
>