ghci 7.4.1 no longer loading .o files?

[Simon Marlow]

On 02/03/2012 04:21, Evan Laforge wrote:
> On Tue, Feb 28, 2012 at 1:53 AM, Simon Marlow<marlowsd at gmail.com>  wrote:
>> I don't see how we could avoid including -D, since it might really affect
>> the source of the module that GHC eventually sees.  We've never taken -D
>> into account before, and that was incorrect.  I can't explain the behaviour
>> you say you saw with older GHC's. unless your CPP flags only affected the
>> imports of the module.
>
> In fact, that's what I do.  I put system specific stuff or expensive
> stuff into a module and then do
>
> #ifdef EXPENSIVE_FEATURE
> import qualified ExpensiveFeature
> #else
> import qualified StubbedOutFeature as ExpensiveFeature
> #endif
>
> I think this is a pretty common strategy.  I know it's common for
> os-specific stuff, e.g. filepath does this.  Although obviously for OS
> stuff we're not interested in saving recompilation :)
>
>> Well, one solution would be to take the hash of the source file after
>> preprocessing.  That would be accurate and would automatically take into
>> account -D and -I in a robust way.  It could also cause too much
>> recompilation, if for example a preprocessor injected some funny comments or
>> strings containing the date/time or detailed version numbers of components
>> (like the gcc version).
>
> By "take the hash of the source file" do you mean the hash of the
> textual contents, or the usual hash of the interface etc?  I assumed
> it was the latter, i.e. that the normal hash was taken after
> preprocessing.
>
> But suppose it's the former, I still think it's better than
> unconditional recompilation (which is what always including -D in the
> hash does, right?).  Unconditionally including -D in the hash either
> makes it *always* compile too much--and likely drastically too much,
> if you have one module out of 300 that switches out depending on a
> compile time flag, you'll still recompile all 300 when you change the
> flag.  And there's nothing you can really do about it if you're using
> --make.

There is a way around it: create a .h file containing "#define 
MY_SETTING", and have the Haskell code #include the .h file.  The 
recompilation checker does track .h files:

http://hackage.haskell.org/trac/ghc/ticket/3589

When you want to change the setting, just modify the .h file.  Make sure 
you don't #include the file in source code that doesn't depend on it.

Cheers,
	Simon

>  If you try to get around that by using a build system that
> knows which files it has to recompile, then you get in a situation
> where the files have been compiled with different flags, and now ghci
> can't cope since it can't switch flags while loading.
>
> If your preprocessor does something like put the date in... well,
> firstly I think that's much less common than switching out module
> imports, since for the latter as far as I know CPP is the only way to
> do it, while for dates or version numbers you'd be better off with a
> config file anyway.  And it's still correct, right?  You changed your
> gcc version or date or whatever, if you want a module to have the
> build date then of course you have to rebuild the module every
> time---you got exactly what you asked for.  Even if for some reason
> you have a preprocessor that nondeterministically alters comments,
> taking the interface hash after preprocessing would handle that.  And
> come to think of it, these are CPP flags not some arbitrary pgmF...
> can CPP even do something like insert the current date without also
> changing its -D flags?