Reduce the number of derivations

[hamishmack]

• Share the default setup executable.
• Make configFiles and ghc outputs of the component derivation.
• Use propagatedBuildInputs and pkgsHostTarget for component dependencies.

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• ci/hydra:Cardano:haskell-nix:required

[hamishmack]

bors try

[hamishmack]

bors try-

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• buildkite/haskell-dot-nix

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• ci/hydra:Cardano:haskell-nix:required

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• buildkite/haskell-dot-nix

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• buildkite/haskell-dot-nix

[hamishmack]

bors try

[iohk-bors]

try

Build failed:

• buildkite/haskell-dot-nix

[L-as]

Not sure I understand. Can you give and example of something in the haskell.nix code we should be avoiding?

E.g., you're removing usages of runCommand, but if you make runCommand not use stdenv, it would probably be faster

The goal here is to reduce the eval time when no code needs to built. My aim was to reduce the amount and size of the derivations in the hope that eval would be faster over all.

Do you mean when you don't need to rebuild the Haskell code, or when no derivation needs to be built at all? In the latter case, optimising derivations won't do much of a difference anyway.
@aciceri (from @mlabs-haskell) was working on optimising IFD in Nix itself as part of https://input-output.atlassian.net/browse/OBT-325 (see https://github.com/mlabs-haskell/nix/tree/parallel-ifds-processes), albeit the funding for this has been removed. The problem is outlined in NixOS/nix#6299, essentially, Nix currently blocks on IFD rather than continuing evaluation and potentially doing multiple IFDs at the same time (since multiple things can be built at the same time). Just removing this limitation would have sped up haskell.nix quite a bit.
Nix evaluation is in general much slower than it could be, and even a 10x speed-up doesn't seem far-fetched to me with enough work. E.g. last time I checked the data type for values was 32 bytes even though 8 would be enough.

Once this change is merged I was going to look into how much could be saved by move the large configurePhase and buildPhase and installPhase strings into static shell scripts that use env variables as inputs (that is why this change uses pkgsHostTarget environment variable).

I'm not sure how fast passing things through the environment is, but it's possible that setting __structuredAttrs = true; in the derivation and using the JSON passed in instead would be a bit faster.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[hamishmack]

This work has been merged in #1854 (except pkgconfigSelector which I don't think we need any more)