[project @ 2003-06-04 15:47:58 by simonmar]
authorsimonmar <unknown>
Wed, 4 Jun 2003 15:47:59 +0000 (15:47 +0000)
committersimonmar <unknown>
Wed, 4 Jun 2003 15:47:59 +0000 (15:47 +0000)
commit70b6c54b3c140d96b69287f8f400f88a0b7e9c18
treea9330da8ebd68a6187be3933fa185f49057bbcb5
parent4d65dec814743bb685ea590503bb54dd5b18023b
[project @ 2003-06-04 15:47:58 by simonmar]
Grrr, started off making a small bugfix and ended up doing a major
cleanup operartion.

Anyway, the problem was that -odir wasn't putting the object files in
the right place when the module in question has a hierarchical name.
This was due to the object filename being generated in two different
places: once by the compilation pipeline machinery, and again in the
Finder.  It now works properly when --make is used; I haven't managed
to fix it for one-shot compilations though (some replumbing is
needed).

While I was here, I cleaned up the compilation pipeline machinery
somewhat.  The previous scheme of generating a data structure
representing the phases that need to be executed before actually
executing them was wrong because the structure of the pipeline can
change while it is being executed (eg. if we see {-# OPTIONS -fasm #-}
during the CPP phase).  There were various hacks to deal with this,
but it turned out to be quite messy.

So the new story is that each compilation phase returns the name of
the next phase to execute, and also figures out which file to put its
output in.  This unfortunately means that the knowledge about what
phases are done in what order is now spread throughout the module, but
there are fewer hacks at the higher levels, and overall it seems to be
an improvement.
ghc/compiler/main/DriverMkDepend.hs
ghc/compiler/main/DriverPhases.hs
ghc/compiler/main/DriverPipeline.hs
ghc/compiler/main/DriverUtil.hs
ghc/compiler/main/Main.hs