Wed, 27 Jun 2001 11:57:06 +0100, Simon Marlow <[EMAIL PROTECTED]> pisze:
> I'm in two minds about what to do. GHCi's behaviour is safe, but it
> results in random superfluous recompilations if you happen to touch &
> recompile really quickly (this happens in our automatic GHCi tests, for
> example). Make's behaviour is unsafe, but from the user's point of view
> it is more deterministic (no unnecessary recompilations).
I would choose the make's behavior. It's much more probable that a
compilation will take a second (when a Makefile generates Haskell
source and then compiles it) than that the next version of the file
after previous compilation will come in a second (the next version
comes from a human; I doubt that any Makefile will compile a file,
then modify it, then compile it again into the same object file).
As we are at it, there is another case. Makefiles typically contain
the following rule:
%.hi: %.o
@true
But when .o is newer than .hi, which happens often in ghc, this
rule unnecessarily fires on each make run for each file (as a side
effect, make doesn't say that everything is up to date). I am using
a different rule:
%.hi: %.o
@touch -c $@
The -c option ensures that we will only adjust the timestamp, not
create an empty file if .o is present without .hi by mistake.
If ghc ensured that .o it creates is not newer than .hi, the simpler
rule with @true would work better.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZAST�PCZA
QRCZAK
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
