Cabal repl and cabal build/run conflict over .o object files if ghci has -fobject-code set

[Thra11]

Not sure if this is really a cabal issue or a ghci issue, so apologies if it's not a cabal issue.

Using a cabal sandbox, if ~/.ghci contains :set -fobject-code, then both cabal repl and cabal compile haskell sources into .o files located in the same place e.g. dist/build/Package/Module.o. However, despite sharing the file locations, they do not appear to link/load objects built by the other process. Instead, switching from one to the other results in recompiling all the .o files, even if the source file hasn't changed and doesn't depend on a file that has changed.

Just using cabal repl will only recompile the modules affected by changes if you do e.g. :r.
Just using cabal build will likewise only recompile as necessary.
However, switching from one to the other will recompile all modules.

I came across this issue because I was trying to use cabal repl for experimentation as I wrote my code, and cabal run (which effectively performs a cabal build) to run my application.

Disabling -fobject-code in ghci is possible as a workaround, but it's not ideal.

[ezyang]

Even if it's a GHC issue, it's an issue Cabal can work around.

What happens if you try using the new-build interface? http://blog.ezyang.com/2016/05/announcing-cabal-new-build-nix-style-local-builds/

[Thra11]

It looks like using cabal new-build and cabal new-repl exhibits similar behaviour, but with both commands putting object files in dist-newstyle/build/foo-0.1.0.0/build/Foo/Bar.o instead of dist/build/Foo/Bar.o.

There is also an additional issue where if cabal new-build fails, cabal new-repl will error as follows, even if the sources have since been fixed (It won't try to rebuild). It will not succeed until cabal new-build has been run again.

$ cabal new-repl
In order, the following will be built (use -v for more details):
foo-0.1.0.0
cabal: '/usr/bin/ghc' exited with an error:
<command line>: Failed to load interface for ‘Foo.Bar’
Use -v to see a list of the files searched for.

One further quirk is that unlike cabal build, cabal new-build will not rebuild everything if nothing has changed, but it will rebuild all the 'shared' object files as soon as one of the source files changes (cabal build will rebuild all the 'shared' object files regardless of whether any of the sources haven't changed).

You can get away with using a mismatched pair, i.e. cabal build with cabal new-repl or cabal new-build with cabal repl, presumably because they put their object files in different locations.

[ocharles]

Is running with --builddir a valid work around? That is, cabal new-repl --builddir=dist-repl

[robrix]

I’ve been seeing the same behaviour (with the new-* commands), plus in some cases building/running/testing will actually fail when switching between those actions and the REPL. (I’m additionally using -fwrite-interface which could be the culprit there? I’m not sure.)

@ocharles: I haven’t tried that workaround (will be doing so today), but ideally I’d like to share build products between the REPL and other builds. I basically live in the REPL all day, and I’d like to be able to quickly run the tests with no recompilation of library code that I’ve got loaded in the REPL. So while avoiding these errors would be nice, I’d still be doing a bunch of redundant building that I’d prefer to avoid.

[robrix]

I’m pretty sure the failure I mentioned is the same issue as #6059.