Have setup-info support specification of a ghc build directory

[mgsloan]

I haven't put a great deal of thought into this idea, but it seems like it's a good feature for those developing on GHC while using stack. The idea is to allow pointing at the root of a GHC source tree, or its inplace dir, and running it directly out of there.

So, in your global config.yaml, you could have something like the following:

ghc:
    linux64:
        8.0
            version: 8.0.2
            ghc-source-path: /home/mgsloan/oss/haskell/ghc

And it would magically use your development version of GHC!

I hope to be returning to iterating on my in-flight ghc patch soon, so that will be a good excuse to revisit this.

[simonmar]

I don't understand why you need a special feature for this. Why wouldn't it work to just tell Stack to use ~/ghc/inplace/bin/ghc-stage2? This is what we do with Cabal & cabal-install. (there's a bit of special magic I believe to find the relevant ghc-pkg program, but it's not hard)

[mgsloan]

Good point @simonmar, thanks for commenting ! It is because I am not yet familiar with GHC development workflows.

With that considered, this would look like:

ghc:
    linux64:
        8.0
            version: 8.0.2
            bin-path: /home/mgsloan/oss/haskell/ghc/inplace/bin/ghc-stage2

Bumping priority to P1 because this isn't very hard and I would love to make GHC folks' lives easier in the next release.

[simonmar]

Ok that's good, but would it be possible to omit the version number? You can infer the version number by invoking GHC with --version.

[mgsloan]

@simonmar This is an element of the data type that provides an index of how to install a large number of tools - https://github.com/fpco/stackage-content/blob/master/stack/stack-setup-2.yaml - which is why I thought the version number would be mandatory. It might make sense to introduce a new thing:

local-ghc-paths:
  - /home/mgsloan/oss/haskell/ghc/inplace/bin/ghc-stage2

Most invocations of stack would then enumerate the list and ask each for their --version, and use if appropriate. I think this is better, because we don't want the online version of stack-setup.yaml to be able to have local directories.

[Blaisorblade]

👍 to this feature. However, is it enough for GHC developers? I can foresee problematic scenarios. Generally: this is a bit harder than with Cabal since Stack tries to be smarter and pick an appropriate GHC by major (and minor) version. And has additional caching smarts (that don't use GHC's global repo) that assume a fixed GHC.

@simonmar Do you rebuild GHC in place? If so, what happens to existing build products built with the previous GHC currently, do you always delete them? Because Stack has more aggressive caching that might get in the way. Luckily, built libraries are only shared across snapshots that use the same GHC version, so destroying those snapshots by hand would be easy-ish.

Ok that's good, but would it be possible to omit the version number? You can infer the version number by invoking GHC with --version.

Minor nitpick: when should that be inferred? Can we query them each time we start stack and need a GHC (maybe in parallel if needed)? That might be easiest, even though here each ghc --version takes ~0.1s:

$ time ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.2

real	0m0.096s
user	0m0.046s
sys	0m0.038s

(This is an rMBP 13'' 2013, it doesn't get much faster than this).

Otherwise, we'd need caches and some cache invalidation, but even invalidation by timestamp could be fooled, so avoiding it would be nice.

[harpocrates]

Is this still happening? It is a bit of a showstopper for using Stack with GHC development.

Is there an alternate proposed workflow that has evolved since when this ticket was opened?

[snoyberg]

I'm not following the motivation here. Is there a reason setting the PATH doesn't work for this use case?

[simonmar]

Yes - firstly I don't want to change my PATH, and secondly the executable is called ghc-stage2 and not ghc or ghc-8.8.