The proper solution would be (described in the issue):
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
But the ghcWrapper is used in:
parseModuleFromString and parseModuleApiAnnsWithCpp in Language.Haskell.GHC.ExactPrint.Parsers
and in a dozen of functions in Test.Transform (we dont have to worry about those ones)
a pair of functions in InsertSignature (it is an example and we can ignore them)
Create duplicate versions of both parse* and push them downstream (in the lib and the downstream packages) will be non trivial.
Using the system env as a global variable is dirty (but arguably better than the fixed at compiled time actual libdir) but quick and dont require changes in downstream packages.
I am not pride of this so i will understand if it is not accepted :smile:
alanz
commented
3 years ago
But the ghcWrapper is used in:
parseModuleFromStringandparseModuleApiAnnsWithCppinLanguage.Haskell.GHC.ExactPrint.ParsersTest.Transform(we dont have to worry about those ones)InsertSignature(it is an example and we can ignore them)Create duplicate versions of both parse* and push them downstream (in the lib and the downstream packages) will be non trivial. Using the system env as a global variable is dirty (but arguably better than the fixed at compiled time actual libdir) but quick and dont require changes in downstream packages.
I am not pride of this so i will understand if it is not accepted :smile: