-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using ghc-paths
makes downstream executables non portable
#96
Comments
As the package is using the libdir only in the public function ghc-exactprint/src/Language/Haskell/GHC/ExactPrint/Parsers.hs Lines 155 to 159 in 81c2ef9
|
Besides If such functions take an additional libdir parameter, does that solve your problem? ghc-exactprint doesn't know the path to the ghc executable, so I'm not sure how "a runtime call to ghc" would work. |
the direct solution i can think off is pushing the ghc wrapper (better then the libdir location imo) or the data that is extracted using it (dynflags and...) downstream and require client code to provide it, in a new function (or several), falling back to the actual one EDIT: whoops you were suggesting just that 😄 |
Tbh i think #98 only can be a temporary workaround, as the code using env it is not thread safe anymore (among other considerations). |
/opt/ghc/8.8.4/lib/ghc-8.8.4/settings: openFile: does not exist (No such file or directory)
ghc-path
, as it stores the ghc libdir at compile timeghc-exactprint/src/Language/Haskell/GHC/ExactPrint/Parsers.hs
Line 289 in 81c2ef9
hie-bios
:https://github.com/mpickering/hie-bios/blob/5eede133dbe82d158591a2c8d0361b3d188192ed/src/HIE/Bios/Environment.hs#L66-L81
But is supposes a runtime call to ghc, that in turn could need be called through stack or cabal, maybe too much.
Or take the way of let downstream packages inform the libdir location, or the
ghcWrapper
as a callback... 🤔The text was updated successfully, but these errors were encountered: