You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 25, 2020. It is now read-only.
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.