alanz / ghc-exactprint

GHC version of haskell-src-exts exactPrint
BSD 3-Clause "New" or "Revised" License
70 stars 32 forks source link

Using `ghc-paths` makes downstream executables non portable #96

Open jneira opened 4 years ago

jneira commented 4 years ago

https://github.com/alanz/ghc-exactprint/blob/81c2ef9cdcf284724df0d66ef1fe5616fdc8ae6c/src/Language/Haskell/GHC/ExactPrint/Parsers.hs#L289

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 ghcWrapperas a callback... :thinking:

jneira commented 4 years ago

As the package is using the libdir only in the public function withDynFlags, remove its use downstream should fix the issue

https://github.com/alanz/ghc-exactprint/blob/81c2ef9cdcf284724df0d66ef1fe5616fdc8ae6c/src/Language/Haskell/GHC/ExactPrint/Parsers.hs#L155-L159

zliu41 commented 4 years ago

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.

jneira commented 4 years ago

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:

jneira commented 3 years ago

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.