FWIW, I use the docker image, as per https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#Docker, where I have the invocation in a one-line script
Alan On 26 January 2017 at 19:38, Phyx <loneti...@gmail.com> wrote: > But do you really want to do this? > > It seems to me you don't want to keep using your stage0 while working on > ghc. As you don't want to break it and spend hours wondering why your build > failed. > > Fair enough, if people want to do this. So long as it's not the defacto > method. > > On Thu, 26 Jan 2017, 17:28 Matthew Pickering, <matthewtpicker...@gmail.com> > wrote: > >> I think the intention is that if you are already using stack to manage >> your GHC installations then it is desirable to use their managed >> version of GHC rather than have to install another version. >> >> It seems to me that the solution that Harendra suggests is the easiest >> for anyone with this setup. >> >> Fwiw, the easiest way I found to setup a clean development environment >> for GHC was to use the nix ghcHEAD derviation. >> >> nix-shell '<nixpkgs>' -A haskell.compiler.ghcHEAD >> >> but of course, this only works if you are using nix! >> >> Matt >> >> On Thu, Jan 26, 2017 at 5:18 PM, Phyx <loneti...@gmail.com> wrote: >> > Can I ask a silly question. I can't seem to find where stack is >> recommended >> > for ghc development on the newcomers page, but why is it? I don't want >> to >> > start another flame war but I can't imagine any scenario where this is >> > useful. As far as I understand the whole benefit of stack is the curated >> > packages. >> > >> > Which are moot here since almost everything you need is in the tree >> aside >> > from Happy and Alex. Seems to me this is just overcomplicating a very >> simple >> > process. >> > >> > Not to mention if you have to go through stack - - exec etc all for >> > interactions with the build artifacts it would get old quickly. Also it >> > doesn't seem reliable especially if stack is modifying the environment >> and >> > or flags passed to the compiler. >> > >> > Let me reiterate, I have nothing against stack, I just don't see the >> > benefits here. Ideally you'd want your environment as simple and >> vanilla as >> > possible and *totally* in your control IMHO. >> > >> > What am I missing here? >> > >> > Thanks, >> > Tamar >> > >> > >> > On Thu, 26 Jan 2017, 14:21 Harendra Kumar, <harendra.ku...@gmail.com> >> wrote: >> >> >> >> I use "export PATH=`stack path --bin-path`" to make the stack installed >> >> ghc available in the PATH before building ghc. And that's all. >> >> >> >> Setting the PATH works better because we do not get any extra env >> >> variables set by stack in the environment and we do not go through the >> stack >> >> wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH >> >> variable set by the stack command is especially troublesome in some >> cases. >> >> You can try "stack exec env" to check all vars that stack puts in your >> >> environment. >> >> >> >> -harendra >> >> >> >> On 26 January 2017 at 15:52, Marius Ghita <mhi...@gmail.com> wrote: >> >>> >> >>> Following is a list of steps that I ran and their output linked: >> >>> >> >>> - clone repo >> >>> https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b >> >>> - build.mk configuration >> >>> https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675 >> >>> - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf >> 3f >> >>> - configure >> >>> https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13 >> >>> - make FAILS >> >>> https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c >> >>> >> >>> I'm using a 'stack-ghc' executable, that's only a shell wrapper to run >> >>> ghc from stack (since I don't have a globally installed ghc) (source >> >>> https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ), >> and I >> >>> also have 'ghc-pkg' wrapped in the same way with >> >>> a stack-ghc-pkg script (source >> >>> https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e ) >> >>> >> >>> -- >> >>> Google+: https://plus.google.com/111881868112036203454 >> >>> >> >>> _______________________________________________ >> >>> ghc-devs mailing list >> >>> ghc-devs@haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >>> >> >> >> >> _______________________________________________ >> >> ghc-devs mailing list >> >> ghc-devs@haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs