Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

haskell: build Setup.hs with a separate pkgdb #39735

Closed
wants to merge 3 commits into from

Conversation

@kirelagin
Copy link
Member

@kirelagin kirelagin commented Apr 30, 2018

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 kirelagin requested a review from peti as a code owner Apr 30, 2018
@kirelagin
Copy link
Member Author

@kirelagin kirelagin commented Apr 30, 2018

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
Copy link
Contributor

@mpickering mpickering commented Apr 30, 2018

@angerman
Copy link
Contributor

@angerman angerman commented May 1, 2018

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
Copy link
Member Author

@kirelagin kirelagin commented May 1, 2018

@kirelagin
Copy link
Member Author

@kirelagin kirelagin commented May 1, 2018

@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
Copy link
Member

@Ericson2314 Ericson2314 commented May 4, 2018

@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 Ericson2314 mentioned this pull request May 13, 2018
1 of 8 tasks complete
@Ericson2314
Copy link
Member

@Ericson2314 Ericson2314 commented May 13, 2018

@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.

@Ericson2314 Ericson2314 mentioned this pull request May 17, 2018
0 of 8 tasks complete
@kirelagin
Copy link
Member Author

@kirelagin kirelagin commented May 24, 2018

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

@Ericson2314
Copy link
Member

@Ericson2314 Ericson2314 commented May 24, 2018

#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
Copy link
Member

@peti peti commented May 27, 2018

#40996 has landed in master.

Ericson2314 and others added 3 commits Jun 13, 2018
This decreases complexity and ensures setup dependencies are properly
specified with `setup-depends` as they should be. Testing will say if
this is a reasonable change.
@Ericson2314 Ericson2314 force-pushed the kirelagin:haskell-setup-hs-pr branch from ed9b51c to d416624 Jun 18, 2018
@mmahut
Copy link
Member

@mmahut mmahut commented Aug 3, 2019

What is the status of this pull request?

@Ericson2314
Copy link
Member

@Ericson2314 Ericson2314 commented Aug 15, 2019

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

@cdepillabout
Copy link
Member

@cdepillabout cdepillabout commented May 5, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

8 participants
You can’t perform that action at this time.