docker GHC image for hacking

[Greg Weber]

On Wed, Dec 10, 2014 at 3:06 AM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> On 2014-12-09 at 23:47:01 +0100, Greg Weber wrote:
> > I added documentation to
> > https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux and
> linked
> > from https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/MacOSX
>
> Btw, you write
>
> > This way you can still hack on GHC with Emacs, etc, but you are just
> > building from the docker container.
>
> ...does that mean you can't invoke `make` directly from within Emacs via
> `M-x haskell-compile`?
>

The build needs to happen from the docker container.
So you would need to modify your make command to run the container.

   docker run `pwd`:/home/ghc gregweber/ghc-haskell-dev make


>
> I'm still trying to understand what you meant exactly by "too high an
> overhead to getting started" with GHC development (as I don't consider
> having to basically `apt-get install ...` (and possibly `cabal install
> ...` if your distribution doesn't have a recent alex/happy package) such
> a high overhead to get your system able to compile a cloned GHC source
> tree)
>

Hacking on GHC for the first time is death by a thousand cuts.
Any one part of the process is not that bad, but as a whole the process is
very cumbersome for someone new.

Running an apt-get line is not too bad if it actually works.
The apt-get instructions on the wiki did not list all of the development
dependencies (it may now since I updated the documentation).
It also doesn't mention arc (that is on a different page and a more manual
installation).

As a casual contributor though, my first thought is to question whether I
want to install more dependencies.
They will clutter my system since I won't remember to remove them later and
they could end up conflicting with another project.
Using a sandbox removes this hesitation.

Again, this is just the first step to using GHC, by itself it is not that
bad, but there is much more to the process for a newcomer.



> So I'd like to identify what you consider an overhead to improve the
> underlying issues to make it easier for interested parties to get up and
> running with GHC development.
>
> Cheers,
>   hvr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20141210/c165e014/attachment.html>