ghci 7.4.1 no longer loading .o files?
marlowsd at gmail.com
Fri Mar 2 10:08:11 CET 2012
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
> import qualified StubbedOutFeature as ExpensiveFeature
> 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
> 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
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:
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.
> 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?
More information about the Glasgow-haskell-users