<div dir="ltr">hey All,<div style>I&#39;ve been spending a bunch of time the past week or so understanding the ghc compilation driver design and also some bits of of the RTS.</div><div style><br></div><div style>1) there seems to be bit of cruft, or at least some comments in the code is no longer true in various places.  eg <a href="http://hackage.haskell.org/trac/ghc/ticket/7907">http://hackage.haskell.org/trac/ghc/ticket/7907</a> is a teeny patch to make one comment about stgclosure c types more accurate. Another example is <a href="https://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs#L803">https://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs#L803</a> which mentions the -fvia-c backend in  2-3 places</div>

<div style><br></div><div style>2) when the ghc driver is used to manage building c code for subsequent ffi usage, it doesn&#39;t seem possible to use a c compiler to do  *.c -&gt; *.o/dylib, instead it is only possible to do *.c-&gt;  *.s  -&gt; *.o/dylib.  </div>

<div style><br></div><div style>I&#39;m curious about reasons c,s,o  choice that are still in play. It makes total sense historically from when the -fvia-c backend, but I&#39;m trying to understand why it is still done this way. (and yes, I&#39;m aware that its pretty easy to have the c compilation be done out of band using a more standard make like tool, I&#39;m simply curious about the current design, because theres not really any information in the commentary thats still current)</div>

<div style><br></div><div style>thanks</div><div style>-Carter</div></div>