understanding ghc compilation driver architecture

[Carter Schonwald]

hey All,
I'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.

1) there seems to be bit of cruft, or at least some comments in the code is
no longer true in various places.  eg
http://hackage.haskell.org/trac/ghc/ticket/7907 is a teeny patch to make
one comment about stgclosure c types more accurate. Another example is
https://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs#L803which
mentions the -fvia-c backend in  2-3 places

2) when the ghc driver is used to manage building c code for subsequent ffi
usage, it doesn't seem possible to use a c compiler to do  *.c ->
*.o/dylib, instead it is only possible to do *.c->  *.s  -> *.o/dylib.

I'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'm trying to
understand why it is still done this way. (and yes, I'm aware that its
pretty easy to have the c compilation be done out of band using a more
standard make like tool, I'm simply curious about the current design,
because theres not really any information in the commentary thats still
current)

thanks
-Carter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130515/f4d2cc78/attachment.htm>