On Wed, Dec 10, 2014 at 3:06 AM, Herbert Valerio Riedel <[email protected]> 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 >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
