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

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

Open
DanielG opened this issue Sep 18, 2015 · 5 comments
Open

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

DanielG opened this issue Sep 18, 2015 · 5 comments

Comments

@DanielG
Copy link
Owner

DanielG commented Sep 18, 2015

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 DanielG added this to the v5.5.0.0 milestone Sep 18, 2015
@DanielG
Copy link
Owner Author

DanielG commented Sep 18, 2015

cc @wolftune

@DanielG
Copy link
Owner Author

DanielG commented Sep 3, 2016

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
Copy link
Owner Author

DanielG commented Jun 21, 2017

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
Copy link

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
Copy link
Owner Author

DanielG commented Jul 29, 2018

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants