Skip to content
This repository was archived by the owner on Apr 25, 2020. It is now read-only.
This repository was archived by the owner on Apr 25, 2020. It is now read-only.

Implement worker/wrapper split, support multiple GHC versions #615

@DanielG

Description

@DanielG

We've had this limitation for quite a while and people seemed not to be too
bothered by it, but with the appearance of Stack this quickly escalated because
now people can switch between different GHC versions without even knowing, since
Stack handles this for them.

The problem right now is that ghc-mod links against ghc (the library) and this
needs to be the same version as ghc (the executable) the user is using
otherwise it's just not going to work.

There are many possible solutions to this, unfortunately all the easier ones
involve pushing knowledge about ghc-mod's concept of project types into the
frontends and keeping that in sync in the future which is probably not a good
idea.

One of the more sensible ways to solve this would be to split ghc-mod into two
packages:

  • one which is essentially what we have now: the library, and the main
    ghc-mod executable that links to ghc (the library), let's call that one
    ghc-mod-main
  • and the other package which is just the ghc-mod/ghc-modi executables which
    don't depend on ghc (the library) at all and only check which GHC version
    we're using and compile the former package for that ghc at runtime (much like
    what cabal-helper does for the Cabal library which seems to be working really
    well).

I don't think I will have time to work on this any time soon but if anyone wants
to give this a shot I'd be happy to point them in the right direction.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions