Haskell Tooling For Core

[wduncanfraser]

I'm opening this issue to discuss bringing Haskell tooling into core (Primarily GHC, cabal-install, and stack), and so we can settle on an approach we all like. There have been two PRs opened to date (#354 and #513) that take different approaches to GHC and Stack. I did my own implementation for building our internal projects and have published them at https://github.com/alasconnect/habitat-plans (As well as some other haskell tools such as happy, alex, dbmigrations, and shellcheck which are built with GHC/cabal-install).

We should probably take this one at a time since the packages are dependent on each other.

Starting with GHC:
I used @themightychris 's build to bootstrap GHC 8.0.1 and my implementation of a GHC plan is very similar to @dmp1ce with the main differences being that I exposed the pkg_include_dirs and setup the libffi include so that it doesn't require hard-coding of the libffi version. For reference, here are the Homebrew and Arch Linux plans that take a very similar approach.

Some discussion points for GHC:
Different projects, especially projects that use Stack and Haskell LTS releases are tied to specific GHC versions, and would want to have an up to date build of the required GHC version. For example: LTS-7 uses GHC 8.0.1 and LTS-8 uses GHC 8.0.2. Would it make sense to maintain separate plans for each version of GHC so they can all get up to date builds for dependency changes (And since GHC depends on itself to build and you can't build older versions with newer)? Or would it be good enough to just have previous versions as builds on the depot since GHC is largely used only as a pkg_build_dep (Though I could see this causing issues when building projects that depend on ncurses or similar deps of GHC itself).

Additionally, I did not include the bash autocomplete components of GHC in my plan as I wasn't sure if it made sense for Habitat since it's largely a build and automation environment, not user-space. What are others feelings on this?

I'm opening a PR with just my implementation of GHC starting at version 8.0.1. Additionally, I ran into issues building internal projects that depended on ncurses when using GHC builds compiled with the core/ncurses plan so we would probably want #613 resolved prior to merging GHC.

[themightychris]

FWIW the approach to versions I'd most like to see is just keeping the latest plan in the core-plans repo with old commits available for past versions if they need to be rebuilt, and then use habitat's natural versioning as much as possible (so a project might list core/ghc/8.0.1 in its pkg_build_deps)

Also +1 to not including the bash stuff

[dmp1ce]

I don't think the bash completion is needed either.

I'm surprised GHC cannot build older versions of itself, but I have never tried. Stack is supposed to be able to download different versions of GHC depending on the stack.yml, but that functionality isn't working for me. Stack issue thread says it might be an issue upstream with GHC. commercialhaskell/stack#3144

#616 looks good to me!

[wduncanfraser]

GHC, cabal-install, alex, and happy have all been merged into core. All that is left is stack. I'll be working on that here soon.