How do I build GHC 7.6 from source?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

How do I build GHC 7.6 from source?

Iavor Diatchki
Hello,

I was just trying to build the GHC-7.6 branch from source and the build failed with type-errors, because the libraries used by GHC have moved on since the release, and "sync all" just gets the most recent version.

Is there a "fingerprint" somewhere so that I can checkout the libraries in a suitable form for building 7.6?

More generally, I run into this problem all the time with people trying to build the branch I work on, so it really would be nice if we started using sub-modules to keep track of this dependency.  I talked to folks at ICFP about this, and one idea was that we could check in the "fingerprint" for a branch into the repo, and track the dependencies this way, but this is exactly what git's submodule machinery does, so it seems pointless to implement the functionality which is already there with a standard interface.  Thoughts?

-Iavor



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: How do I build GHC 7.6 from source?

Ian Lynagh-2
On Tue, Sep 18, 2012 at 12:48:13PM -0700, Iavor Diatchki wrote:
> Hello,
>
> I was just trying to build the GHC-7.6 branch from source and the build
> failed with type-errors, because the libraries used by GHC have moved on
> since the release, and "sync all" just gets the most recent version.

Use this:
    http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Gettingabranch
to get the ghc-7.6 branch.

Why do you want to build 7.6 but not 7.6.1, OOI?

> More generally, I run into this problem all the time with people trying to
> build the branch I work on, so it really would be nice if we started using
> sub-modules to keep track of this dependency.  I talked to folks at ICFP
> about this, and one idea was that we could check in the "fingerprint" for a
> branch into the repo, and track the dependencies this way, but this is

See
    http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystate

The nightly build logs include a fingerprint.

> 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


Thanks
Ian


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: How do I build GHC 7.6 from source?

Iavor Diatchki
Hello,

On Tue, Sep 18, 2012 at 1:25 PM, Ian Lynagh <[hidden email]> wrote:
Why do you want to build 7.6 but not 7.6.1, OOI?

 I was trying to build a different branch which is a fork of 7.6---I wanted to play around with the profiling suite described in the "Core Diving" talk from the Haskell Implementors workshop.


> More generally, I run into this problem all the time with people trying to
> build the branch I work on, so it really would be nice if we started using
> sub-modules to keep track of this dependency.  I talked to folks at ICFP
> about this, and one idea was that we could check in the "fingerprint" for a
> branch into the repo, and track the dependencies this way, but this is

See
    http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources#Trackingthefullrepositorystate

The nightly build logs include a fingerprint.
 
Where are the nightly build logs?


 > 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


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).

-Iavor
 
 

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: How do I build GHC 7.6 from source?

Simon Marlow-7
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
>
>
> 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


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: How do I build GHC 7.6 from source?

Claus Reinke
> 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.

Since you already have fingerprinting in place, have you looked
into 'git subtree' for the remaining functionality? Used to be an
addon module, has recently been merged into git (contrib/).

http://apenwarr.ca/log/?m=200904#02

https://github.com/gitster/git/blob/634392b26275fe5436c0ea131bc89b46476aa4ae/contrib/subtree/git-subtree.txt

https://github.com/apenwarr/git-subtree

I don't have further information or recommendations, just wanted
to pass on this alternative - it tends to come up when googling for
'git submodule' issues, and most reports on it have been favorable
(no idea whether it would work for the size and complexity of the
ghc&friends repo landscape).

Claus
 


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: How do I build GHC 7.6 from source?

Iavor Diatchki
In reply to this post by Simon Marlow-7
Hello,

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.

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 <[hidden email]> 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


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



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: How do I build GHC 7.6 from source?

Simon Marlow-7
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 <[hidden email]
> <mailto:[hidden email]>> 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
>
>


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users