-
Notifications
You must be signed in to change notification settings - Fork 176
Implement worker/wrapper split, support multiple GHC versions #615
Comments
cc @wolftune |
After meditating on this problem for a while at MuniHac I've decided the most immediately useful way to fix this is to make the |
FIY I've implemented a new field ( Our |
any updates? (currently trying out visual studio code extension haskero which would be awesome to have some refactoring capabilities) |
Nope. FYI this only applies to ghc-mod, HaRe (and HIE for that matter) have to implement this seperately. |
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 thisneeds to be the same version as
ghc
(the executable) the user is usingotherwise 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:
ghc-mod executable that links to
ghc
(the library), let's call that oneghc-mod-main
don't depend on
ghc
(the library) at all and only check which GHC versionwe'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.
The text was updated successfully, but these errors were encountered: