Open jneira opened 4 years ago
As the package is using the libdir only in the public function withDynFlags
, remove its use downstream should fix the issue
Besides withDynFlags
, ghcWrapper
is also used in some parse functions like parseModuleApiAnnsWithCpp
.
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.
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 :smile:
Tbh i think #98 only can be a temporary workaround, as the code using env it is not thread safe anymore (among other considerations). Not sure if it worths start to work in a better solution for the lib, given it will be included in ghc sooner or later. @alanz iirc you put a link in irc with a new solution for the ghc wrapper but i cant find it out right now, sorry, maybe we could port that one.
/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 timehttps://github.com/alanz/ghc-exactprint/blob/81c2ef9cdcf284724df0d66ef1fe5616fdc8ae6c/src/Language/Haskell/GHC/ExactPrint/Parsers.hs#L289
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... :thinking: