Implement worker/wrapper split, support multiple GHC versions
DanielG opened this issue · comments
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 toghc(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 onghc(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.
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 ghc-mod executable a wrapper for real ghc-mod executables installed into $libexec. The way we deal with concurrent installation of multiple versions is simply to extend the $libexec machinery in our Setup.hs to install executables into a sort of $libexecsubdir which includes the GHC version and architecture in the name (see $libsubdir).
FIY I've implemented a new field (scope: private) in Cabal HEAD (to be released as 2.x) that toggles installing into $libexec/$libexecsubdir which gives us a path like /usr/local/libexec/x86_64-linux-ghc-8.0.2/mypkg-0.1.0/ most importantly containing the GHC and ghc-mod versions. With this structure the wrapper can dispatch to the correct executable.
Our build-type: custom Setup.hs also implements these semantics starting with v5.8.0.0. The coinstall branch contains initial work towards adding the wrapper which currently only works when ghc-mod is actually installed into $libexec (kind of annoying for development).
any updates?
can we already seamlessly use HaRe together with stack for newbies like me?
(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.