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.