> > 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 <[email protected]> wrote: > > 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. > > >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
