How do I build GHC 7.6 from source?
marlowsd at gmail.com
Fri Sep 21 16:55:44 CEST 2012
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.
> 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
> 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?
> 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
> 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.
More information about the Glasgow-haskell-users