haskell: build Setup.hs with a separate pkgdb

[kirelagin]

This is my current attempt at fixing #39646.

As outlined in that issue, I turned Setup.hs of each project into a separate derivation. This makes sense in the context of cross-compilation generally, as the host architecture for ./Setup is that of the builder, not of the host which we are building for.

I have tested the first commit by building pandoc, git-annex and qtah-generator (which ships a less trivial Setup.hs). Then I faced an issue with derivations produced by stack2nix and realised that it was caused by the fact that I ignored postUnpack hooks, thus second commit, which, hopefully, addresses it (I am building it at the moment to see if it worked).

In general I am not very happy about doing all this unpacking and patching twice, it would be great if someone hinted me at how this could be done better.

I am sharing this now to get some advice on whether this direction is the right one in general.

[kirelagin]

Yes, now, everything works. I can compile not only pandoc and qtah-generator (both from nixpkgs and from git via stack2nix), but my projects that failed to build before these commits.

[mpickering]

@angerman

[angerman]

Thanks @mpickering for the ping! Right, this looks a bit more sophisticated than the hack I have in #37254. #37598 also does some improvements in this area.

In general--and what @shlevy also mentioned--we likely really want to encode the build-type from the cabal file in the generated .nix expression by cabal2nix. That way we would know beforehand if we want to depend on the simple or a custom setup.hs.

I haven't looked into that much, as an alternative haskell infra[1,2,3,4], does expose the build-type, and I've been using that primarily for the last few weeks.

--
[1]: https://github.com/angerman/Cabal2Nix
[2]: https://github.com/angerman/haskell.nix
[3]: https://github.com/angerman/hackage.nix
[4]: https://github.com/angerman/stackage.nix

[kirelagin]

@Ericson2314

[kirelagin]

@angerman

we likely really want to encode the build-type from the cabal file in the generated .nix expression by cabal2nix. That way we would know beforehand if we want to depend on the simple or a custom setup.hs

Yes, this will allow us to reuse Setups for standard build types, as what I don’t like currently is that the number of derivations built increased twofold and the output of nix-build looks intimidating. But this optimisation is hardly critical and we can do it later.

[Ericson2314]

@kirelagin I like this :). I, like @angerman, want more more derivations, but as #39646 shows @peti isn't yet on board either. This should be less controversial, yet also be a path towards more derivations as the same helpers can be reused in e.g. per-component derivations. So yeah, I think this is a net improvement while leaving all the doors open. Nice work :).

[Ericson2314]

@peti what do you say to this? I'll happily volunteer to fix the eval errors if @kirelagin doesn't beat me to it, but we need approval on the concept.

[kirelagin]

So what’s the plan?
If there are other ideas how to fix #39646 I’d happily look into them as well.

[Ericson2314]

#40642 (reverted and now #40996) will fix. But I still like this more so hope we can do both. I view the generic-builder parts of the that PR as an incremental step towards this :).

[peti]

#40996 has landed in master.

[mmahut]

What is the status of this pull request?

[Ericson2314]

There is interesting stuff here but I tht the proximate issue is fixed?

[cdepillabout]

There is interesting stuff here but I tht the proximate issue is fixed?

I guess this can be closed then.

If anyone is looking for something that takes the path of turning more things into separate derivations, haskell.nix makes a lot of strides in this area.