> Peter Simons and I have just stumbled on a bug in the CVS version
> of ghc --make that seems to have been introduced since the release
> of 6.0, so I assume it is also buggy in the yet-to-be-released 6.2.
>
> The nub of the bug is that ghc --make now names the object
> file for any
> module Main as Main.o, disregarding the actual filename of the source.
> (Previously, the .o was named to correspond to the .hs source file.)
This is intentional, and is part of a cleaning up of GHC's filename
handling policies that we did recently.
Previously, the .o file followed the filename, but the .hi file followed
the module name. Under this scheme, you would also run into trouble
with having several Main modules in the same directory, because the .hi
filenames would clash. The symptom is that the compiler could
erroneously report "compilation NOT required".
The new story is based on the observation that the .hi file and the .o
file together comprise the object code of the module; they are created
at the same time, and should never be separated. Hence, we made the
rules that govern the filenames for these two files symmetrical. This
is all documented in the User's Guide (unfortunately there isn't an
online version which describes this new behaviour, you have to format it
from the CVS sources).
Of course, you can always circumvent the default behaviour by passing
the appropriate command-line flags.
> When compiling more than one program which inhabit the same filesystem
> directory, this leads the re-compilation dependency analysis astray.
> ghc --make believes that the second Main module has already been
> compiled, and so links a /different/ program's Main.o with the modules
> imported by this program. The resultant linking errors are highly
> confusing until you understand what is going on.
It would certainly be nice to provide some error checking to catch cases
like this - we could store the source filename in the .hi file, for
example. This is one for the ToDo list.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
