resolving ghc symbolic links is incompatible with shim scripts
Closed this issue · 4 comments
I use a shim around ghc https://gitlab.com/fommil/ghc-env which allows me to control the ghc executable that I use on a per-project basis. This is inspired by how the JVM world manages the version of Java.
However, I encountered a problem when using doctest sol/doctest#209 where its invocation of ghc was being resolved to the shim's script rather than the symbolic link to the shim script. That means the shim doesn't know what is being invoked (e.g. ghci and others also point at the shim).
It was hypothesised (in the referenced ticket) that symbolic link resolving is happening inside ghc-paths.
I would be happy to provide a PR to fix this, as it likely impacts many tools. But I wonder if there is a reason why it is the way that it is. Could you please let me know if you foresee any problems with removing the link resolution?
I think I'm just going to scrap the ghc-env shim, and use cabal's built in ghc version resolution mechanism.
@fommil the stack build tool is able to manage GHC versions for you.
Based on stack's code, I wrote ghc-env which is a stand-alone tool to manage GHC versions. Sadly it's bit rotten, so it would need some love to get it working again.
Somewhat related, @snoyberg is looking for volunteers to tackle commercialhaskell/stack#4261 (comment).
@sol lol, it's even the same name as my ghc-env.
I already have a ticket open with stack: it doesn't let me use my own builds of ghc and I do not want to use prepackaged binaries.
btw, I will probably throw away my ghc-env. I found out how to use cabal to manage the ghc version. I will perhaps use your ghc-env, or just the stack download locations, to obtain ghc versions that I can use to bootstrap ghc source builds.