GHC skips recompilation of a module if the module code
hasn't changed, even if the flags in use *have* changed.
A benign version is that switching on -O won't recompile
modules that were compiled without -O. But here's a
nastier version: changing the -main-is flag can lead to an
obscure link error. Details below supplied by Niels
[cpjvelde@cs.uu.nl]
Simon
Actually, i reproduced it now and the reason is a bit
different. I have an
application Test and Test2. They both have a main
function. Test imports Test2
for some other function. So this is how those files look
like:
~/pancake > cat Test.hs
module Test where
import Test2 hiding (main)
main = doit
~/pancake > cat Test2.hs
module Test2 where
doit = print "Test2.doit"
main = print "Test2.main"
I then first compile the first app:
~/pancake > ghc --make -main-is Test.main Test.hs
Chasing modules from: Test.hs
Compiling Test2 ( ./Test2.hs, ./Test2.o )
Compiling Test ( Test.hs, Test.o )
Linking ...
then i compile the second app:
~/pancake > ghc --make -main-is Test2.main Test2.hs
Chasing modules from: Test2.hs
Skipping Test2 ( Test2.hs, Test2.o )
Linking ...
/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0xe): In function
`main':
: undefined reference to `__stginit_ZCMain'
/usr/lib/ghc-6.4/libHSrts.a(Main.o)(.text+0x28): In
function `main':
: undefined reference to `ZCMain_main_closure'
collect2: ld returned 1 exit status
So I guess generating Test2.o the first time and using -
main-is renamed the main
in Test2.o . Since it is not recompiled when I want to
compile the second app,
it fails because it cant find the main...I thought providing
a -main-is flag
again when compiling the second app would somehow
force recompilation of Test2.o
or at least fixing the 'renaming' that the first compilation
of Test2.o had
caused.
greetings, Niels.