Am 28.04.20 um 13:17 schrieb Dominik Schrempf:
By the way, I just failed building the documentation. This is all wrong :|.
src/Data/Matrix/Class/Mutable.hs:10:1: error: Could not find module ‘Control.Monad.Primitive’ There are files missing in the ‘primitive-0.7.0.1’ package, try running 'ghc-pkg check'. Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 10 | import Control.Monad.Primitive (PrimMonad, PrimState) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yes, this is either 'cabal haddock' or just 'haddock' doing a front-end compile phase, give or take. This can be extremely annoying when all you want to have are the docs. But it's strange that you can cabal build but not cabal haddock if you get such errors. Which cabal-install version is this? I agree that in general there are some things that could go smoother. I think part of the problem is that the addition of the backpack support has made cabal even more complicated than it already was, while at the same time the newstyle commands were implemented. Both are extremely valuable features but maintaining such a monster must be hard. I am not involved in cabal development at all and know almost nothing about its internal workings, but perhaps things could be improved by making it a bit more modular; i.e. strive for the traditional Unix approach of "do one thing and do it well". Probably easier said then done, though. Today I ran again into a problem I had several times before: compiling Cabal-3.2.* (the library) with ghc-8.2.2 and cabal with default options (including jobs: $ncpu, though it actually used only one cpu) eats all the memory on my machine (8GB, but I had a tor browser and another browser and thunderbird running) so that it completely freezes (no mouse, no keyboard). Had to reboot using sysrq escape hatch. Not funny. I think this is due to use of ghc --make and some very large modules. Thankfully memory use has improved with later ghc versions. Cheers Ben