Open RichardWarfield opened 5 years ago
fail in what manner?
In what appears to be the same manner as the linked issue:
Preprocessing executable 'ghc-hare' for HaRe-0.8.4.1..
Building executable 'ghc-hare' for HaRe-0.8.4.1..
[1 of 2] Compiling Paths_HaRe ( .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build/ghc-hare/autogen/Paths_HaRe.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build/ghc-hare/ghc-hare-tmp/Paths_HaRe.p_o )
[2 of 2] Compiling Main ( app/MainHaRe.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build/ghc-hare/ghc-hare-tmp/Main.p_o )
/home/richard/workspace/third_party/haskell-ide-engine/submodules/HaRe/app/MainHaRe.hs:26:16: fatal:
cannot find object file ‘.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build/ghc-hare/ghc-hare-tmp/Paths_HaRe.dyn_o’
while linking an interpreted expression
Won't HIE break similarly if you have profiling enabled locally for your project but build HIE with profiling disabled?
I don't know enough about how HIE or its plug-ins work to answer that, but in my limited use of HIE (mainly for linting via Neovim+Coc) it seems to work.
@RichardWarfield Thanks for that info. Your error is precisely the symptom of the problem you are describing in the original issue btw. It's a hard one to debug if you don't know what you're looking for.
Related to #1214, which reports that building with profiling on under
stack
doesn't work.Some developers may have profiling on by default with stack (i.e.
library-profiling: true
andexecutable-profiling: true
in~/.stack/config.yaml
). I do this because I want profiling on more often than I want it off, and because it takes a long time to switch between profiling and non-profiling builds with stack. This configuration caused building HIE to fail and it took quite a while to figure out why.As long as profiling doesn't work out of the box with
stack
, might it make sense ship with profiling explicitly disabled instack-8.x.x.yaml
?