Implement worker/wrapper split, support multiple GHC versions

DanielG commented 8 years ago

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.

DanielG commented 8 years ago

cc @wolftune

DanielG commented 8 years ago

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).

DanielG commented 7 years ago

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).

schlichtanders commented 6 years ago

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)

DanielG commented 6 years ago

Nope. FYI this only applies to ghc-mod, HaRe (and HIE for that matter) have to implement this seperately.

DanielG / ghc-mod

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