[project @ 2003-07-17 12:04:50 by simonmar]
authorsimonmar <unknown>
Thu, 17 Jul 2003 12:04:54 +0000 (12:04 +0000)
committersimonmar <unknown>
Thu, 17 Jul 2003 12:04:54 +0000 (12:04 +0000)
commit6677029a5084f59b4cd35d76ce3f19b154f2ac87
tree08da4b511244d9e7533255efc9ebc2134310df84
parent2a86ebc211c02271fa035f5834eb9f0b2e3bd6e5
[project @ 2003-07-17 12:04:50 by simonmar]
Filename-related cleanup & fixes
--------------------------------

This commit rationalises some of our filename policies.  The new story
is this:

  When compiling a Haskell module A.B.C:

    The object file is placed in <obj-path>/A/B/C.o
    The interface file is placed in <hi-path>/A/B/C.hi

    Where <objpath> is
- the argument of the -odir flag, if one was given
- the element of the search path in which the source file was found,
  when in --make mode.
- "." otherwise.

    Where <hipath> is
- the argument of the -hidir flag, if one was given
- the element of the search path in which the source file was found,
  when in --make mode.
- "." otherwise.

NOTE, in particular, that the name of the source file has no bearing
on the name of the object or interface file any more.  This is a
nchange from the previous semantics, where the name of the object file
would, under certain circumstances, follow the name of the source file.

eg. before, if you said

ghc -c dir/foo.hs

you would get dir/foo.o.  Now, you get something like Main.o,
depending on what module is in foo.hs.  This means that the driver
pipeline machinery now needs to pass around a Maybe ModLocation, which
is filled in by the Hsc phase and used later on to figure out the name
of the object file (this was fairly painful, but seems to be the only
way to get the right behaviour).
ghc/compiler/compMan/CompManager.lhs
ghc/compiler/main/DriverMkDepend.hs
ghc/compiler/main/DriverPipeline.hs
ghc/compiler/main/Finder.lhs
ghc/compiler/main/Main.hs
ghc/compiler/main/MkIface.lhs