Recompilation check should include flags
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 [email@example.com] 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.