GHC API: value for GHC.targetUnitId (solved!)

1

I’ve just been upgrading from ghc 9.2 to 9.6 and as usual, the hardest part is porting to the new GHC API. I’ve been able to figure out most of it, except I need to GHC.setTargets $ map make_target toplevel_modules where make_target is:

make_target :: String -> GHC.Target
make_target module_name = GHC.Target
    { GHC.targetId = GHC.TargetModule (GHC.mkModuleName module_name)
    -- ghci unsets this if the module name starts with *, so I guess it means
    -- you can load the .o or must interpret.
    , GHC.targetAllowObjCode = False
#if GHC_VERSION >= 90601
    , GHC.targetUnitId = GHC.Unit.Types.UnitId "x" -- TODO?
#endif
    , GHC.targetContents = Nothing
    }

The “x” value does not fly: Unit unknown to the internal unit environment. What should it be? There is no package here, these are just local .hs files, which I’m loading to interpret.

Also in the spirit of the GHC API stability effort which I see has been going on, is there any documentation for the GHC API and specifically what changes between versions? I saw various docs talking about what to do, but didn’t see where they mention if there is any existing documentation.

Speaking of documentation, I was just trying to find ghc release notes, and it’s complicated. The most relevant search goes to Welcome to the GHC User’s Guide — Glasgow Haskell Compiler 9.12.2 User's Guide but since only the most recent release notes are included, I have to find earlier versions. Google is a mess of conflicting and ancient stuff, that’s on them though. This seems to be the real deal GHC versions: downloading and status · Wiki · Glasgow Haskell Compiler / GHC · GitLab . Things would be simpler if release notes included past versions, we don’t have to go back to ghc 6, but at least several major stable versions shouldn’t cost that much html space. Anyway I did locate 2.8. Version 9.4.1 — Glasgow Haskell Compiler 9.4.8 User's Guide which is good stuff, but doesn’t mention the Target change.

Looking at the hint source points me to GHC.guessTarget, and looking at its source gets me to currentHomeUnitId <- homeUnitId . hsc_home_unit <$> getSession, but I probably just want guessTarget. Using it directly gets Cannot add module … not interpreted and on a hunch I set GHC.targetAllowObjCode = False and looks like we’re back in business! Whew. So I guess this is no longer a question, but an experience report! It was not actually so bad in the end, but it’s still a bunch of guesswork and trial and error.

Also while I’m here and talking about ghc api stability, I was also upgrading something that uses ghc-lib-parser and that also needs to be upgraded by trial-and-error, I couldn’t find any documentation of what’s changed. I did find a package called hackage-diff but it no longer builds and needs some updating (ironic). Has it been superseded by something better or is it a “volunteers welcome” situation? Also since ghc-lib-parser sets base version constraints, it doesn’t seem to actually fulfill its promise of keeping you isolated from ghc versions. I can’t build ghc-lib-parser == 9.2.5.20221107with ghc 9.6, because the baseversion is too new. I guess there must be good reasons for it, but it seems unfortunate. Does it defeat its purpose? Am I using it wrong? Or expecting too much?

1 Like