Cannot build GHC using the Newcomers guide

Fri Jan 27 10:11:04 UTC 2017

Thank you all for the feedback, I went with Harendra's solution and that
worked fine (and removed any shell wrapping I had to do).

To answer Phyx, using stack has become more convenient for managing ghc
than using the packages my distro offers (which always falls behind the
latest version of GHC by a couple of months), or the alternative of just
downloading binaries and managing that process manually. There might also
be a misunderstanding given your first post, because I only use stack to
provide those ghc (ghc-pkg, alex, happy) binaries, and I'm not managing the
ghc source as a stack package; and what that means is that I don't have to
run `stack exec --` to interact with build artifacts.

On Thu, Jan 26, 2017 at 8:05 PM, Alan & Kim Zimmerman <alan.zimm at gmail.com>
wrote:

> 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 <lonetiger at 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, <
>> matthewtpickering at 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 <lonetiger at 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.kumar at 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 <mhitza at 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/e23df8b9ed2aac5b1b8881c70165b
>>> f3f
>>> >>>  - 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 at haskell.org
>>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >>>
>>> >>
>>> >> _______________________________________________
>>> >> ghc-devs mailing list
>>> >> ghc-devs at haskell.org
>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >
>>> >
>>> > _______________________________________________
>>> > ghc-devs mailing list
>>> > ghc-devs at haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>> >
>>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>

-- 
Google+: https://plus.google.com/111881868112036203454
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170127/ff0be677/attachment-0001.html>