Restructure cabal file into a library with executables that depend on it

[basvandijk]

CI is way too slow and actually fails on darwin. The main reason for the slowness is that each executable rebuilds all the modules from the library.

This PR restructures the cabal file such that the executables depend on the library instead of on the source code of the library. This ensures the library is only built once.

The reason the cabal files was structured like this was to support ghcid. However most active maintainers are not using ghcid so we prefer to have faster builds instead.

Besides restructuring the cabal file this PR also switches building the haddocks from cabal to Nix which allows us to remove the cabal.project and cabal.project.freeze files which has the advantage that a cabal build will then pick the dependencies from the nix-shell instead of building them itself.

[nomeata]

The reason the cabal files was structured like this was to support ghcid. However it seems GHCi supports loading multiple components nowadays.

It does? Last I checked GHC has some basic support, but it has not reached Cabal (for cabal repl yet).

But yes, I am rarely interactively working on this code base right now, so if none else misses this, fine with me.

[basvandijk]

It does?

I didn't actually check it but I followed the linked ticket (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/395) and the associated MRs were merged so I assumed there was better support.

But yes, I am rarely interactively working on this code base right now, so if none else misses this, fine with me.

Thanks. I hope that by this and future restructurings we can lower our CI times and get passed the failing darwin builds on some of our PRs.

[nomeata]

I still wonder how useful the Darwin build is at all. Shipping ic-ref to users never had a strong reason, and for our various CI tasks, Linux only should be fine.

[basvandijk]

I really would like to get rid of it but it seems the sdk depends on it (3cc51be).

[nomeata]

Out of habit or because they care about it? I found https://forum.dfinity.org/t/future-of-the-ic-ref-emulator-dfx-start-emulator/9511 to be rather inconclusive.

[mraszyk]

LGTM

Thank you!

[basvandijk]

Last remaining problem is that the HPC coverage report (nix-build -A coverage) is empty:

as opposed to the one from master:

I'll see how to fix that...

[basvandijk]

Fixed.

BTW it would be cool to also publish the HPC coverage report to our GitHub pages. Will look into that in another PR.

[basvandijk]

BTW I noticed that running nix-build -A coverage gets ic-ref to consume over 16GB of memory which is more than the 14GB the GitHub darwin runner has. This is likely why that job failed on darwin.

[nomeata]

Multi-component cabal repl makes progress: https://well-typed.com/blog/2023/03/cabal-multi-unit/