Skip to content

`COMPILING_BASE_PACKAGE` compiler hard-coding: can we something better?

I was looking at all the places base was hard-coded in the compiler for !7898 (closed) / #20647 (closed) / , and one of the odder things I noticed was in GHC.Driver.Pipeline.Execute

          -- Stub files generated for foreign exports references the runIO_closure
          -- and runNonIO_closure symbols, which are defined in the base package.
          -- These symbols are imported into the stub.c file via RtsAPI.h, and the
          -- way we do the import depends on whether we're currently compiling
          -- the base package or not.
                 ++ (if platformOS platform == OSMinGW32 &&
                        isHomeUnitId home_unit baseUnitId
                          then [ "-DCOMPILING_BASE_PACKAGE" ]
                          else [])

This dates back to 8c84944d.

A few questions here:

  • Surely at the very leat we can put -DCOMPILING_BASE_PACKAGE in base.cabal rather than hard-coding it in the compiler?

  • There are many other base_ variables referenced in the RTS. Are these one only special because they are the only ones used in public header (rts/include?)

  • The are in rts/include/RtsAPI.h because the are entry point to haskell evaluation in some sense, right?

  • The RTS coments mention them being used in base too, but git log -G 'run(Non)?IO_closure' libraries/base turns up nothing. Could we / should we just remove the declarations altogether when compiling base?

(Not in the context of !7898 (closed), s/base/ghc-base/. Every bit of base hard-coding is more headache for that, which I why I would like to dodge all this.)

CC @ketzacoatl @Phyx @bgamari

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information