A plan for ways and cross-compilation?
Ever since we started discussing plans for making GHC runtime-retargetable I have wondered what we should do about the current notion of ways. In general, the way notion is quite unprincipled, conflating matters of code generation and runtime features. Moreover, many of the ways we support don't generalized cleanly to some of the platforms we are considering adding support for (e.g. Webasm and the dyn
way). Furthermore, the existence of ways is introduces a significant amount of complexity in build systems like Cabal. This complicates maintenance as well as causes quite some trouble for users since, e.g., Cabal for a long time didn't track in which ways packages had been built.
Upon further reflection, I might have a way to put the way notion on a more principled footing:
- Ways that only affect RTS linkage (e.g.
threaded
,debug
, andeventlog
, if we don't eliminate the latter entirely as proposed in #18948 (closed)) turn into Cabal flags of therts
package which can be set by the user. This fits nicely with the direction of making the RTS a "normal" reinstallable package - We define the notion of target to be a target platform and additional, GHC-specific code-generation properties
- Ways that affect code generation (e.g.
prof
, tables-next-to-code, unregisterised) turn into a property of the target. That is, we might havex86_64-linux-unknown-vanilla
andx86_64-linux-unknown-prof
targets.
This recognizes the fact that, from the perspective of code generation, ways like prof
and vanilla
are entirely incompatible.
One slight problem with this plan is that -dynamic-too
may be harder to implement, since we will need to run the code generator for two different targets starting from the same Core.