> Simon Marlow <[EMAIL PROTECTED]> writes
>
> > I found one bug recently which could cause this, if you
> have recursive
> > modules and use .hi-boot files.
> >
> > If this isn't the case, you can get more info using the
> -ddump-hi-diffs
> > option, which should give some clue as to why GHC thinks the module
> > needs to be recompiled.
>
>
> My case is the second one.
> And GHC does not report of recompilation need.
> In simply may load interpreted code instead of .o.
> I added -ddump-hi-diffs (to ghc -c and to ghci lines)
> But I cannot reproduce the effect.
> Any simplest Foo.hs would do.
Like this?
--------------
~/scratch > touch Foo.hs && ghc -c Foo.hs && ghci Foo
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.00.2, For Haskell
98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package std ... linking ... done.
Compiling Foo ( Foo.hs, interpreted )
Foo>
----------------
why did GHCi recompile the source? Well, it turns out that the
filesystem only stores modification times to the nearest second, and the
modification times of the source and object in this case are the same,
so GHCi infers that the object isn't up-to-date because it isn't
provably newer than the source.
Why doesn't this happen with 'make'? Well, make uses a different rule
to decide whether to recompile something. It recompiles everything that
is "out of date", where the definition of out-of-date is that the object
is older than the source.
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). In both cases
there is another source of unsafety: if you edit the source *during* a
compilation, then neither system will notice and recompile.
Thoughts, anyone?
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
