Perhaps you can look in the: _build/stage0/libraries/ghc-boot-th-next/. dependencies.mk makefile and seeing which module is bringing in this dependency and then getting rid of that edge.
Oh dear. I am WAY WAY out of my depth
But then I realised that PERHAPS the issue is not
- what modules are in `other-modules`
but rather
- what modules are *depended on* by `othher-modules` *when *BOOTSTRAP_TH
is *not on.*
And indeed that solved it. In ForeignSrcLang I needed to put the extra
import in the branch when BOOSTRAP_TH is *off*, so that it does not depend
indirectly on GHC.Internal.Classes.
It's working now. Wow, that was mysterious.
A writeup of BOOTSTRAP_TH would be valuable. With pointers to it from its
use-sites.
Thanks for helping. I would not have solved it without you.
Simon
On Wed, 25 Mar 2026 at 14:49, Teo Camarasu
But the problem is NOT with that import. It's with the OPTIONS_GHC in GHC.Internal.Classes, which is not in the external-modules section.
Indeed. Hadrian is not smart enough to give us an error here if we attempt to build a module that isn't included in the .cabal file. But if something is bringing it in while building stuff from `ghc-boot-th-next` then the error is that this module is being built. We really shouldn't be building it and we shouldn't need to. At this stage we just want to get the definitions from these TemplateHaskell files and we do not want to build large sections of `ghc-internal`.
Perhaps you can look in the: _build/stage0/libraries/ghc-boot-th-next/. dependencies.mk makefile and seeing which module is bringing in this dependency and then getting rid of that edge.