Skip to content
This repository has been archived by the owner on Aug 2, 2020. It is now read-only.

Add ways to build hadrian using nix #473

Merged
merged 2 commits into from Nov 20, 2017

Conversation

angerman
Copy link
Collaborator

This adds two new files to the hadrian directory

shell.nix sets up the build envrionment you need to build ghc
build-nix is a simple wrapper which invokes hadrian in the correct environment

Note: this patch was authored by @mpickering, however it ended up on phabricator due to the subtree as https://phabricator.haskell.org/D4207.

build-nix Outdated
@@ -0,0 +1,32 @@
#!/usr/bin/env nix-shell
#! nix-shell -i bash shell.nix
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file looks almost identical to build.stack.nix.sh -- what's the difference? Do we need both?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, it is quite similar. But the obvious difference being that this doesn't require stack nor cabal to be installed on your system and is more direct than using a stack.yaml file to specify the nix configuration.

Copy link
Collaborator

@alpmestan alpmestan Nov 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just copied this in my tree for now and would therefore be the second user of this approach. (would like to avoid using stack or cabal-install)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, to use this script one will first have to somehow build Hadrian. This feels like an easy way to shoot oneself in the foot by using an outdated Hadrian binary.

It may be a good idea to separate the two concerns somehow: building Hadrian and building GHC, but this PR seems to only address the latter, but not the former, unless I'm missing something?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I've never used nix, so excuse my naive comments!)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you call this script, it enters the environment specified in shell.nix, which "provisions" among other things a local build of hadrian.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(and it has everything needed for building ghc, too)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@snowleopard
Copy link
Owner

Can we stick to the convention that shell scripts have .sh extension?

A general comment: I am concerned that we keep accumulating too many various build scripts, which can be confusing. Perhaps we should only keep the default build.sh and build.bat at the top level and create a separate directory called scripts for custom build scripts?

@snowleopard
Copy link
Owner

@mpickering @angerman Thanks for the PR and for bringing it here!

shell.nix Outdated
HUnit = nixpkgs.haskell.lib.dontCheck (self.callHackage "HUnit" "1.3.1.2" {});
}; };

hadrian = hadrianPackages.ghcWithPackages (ps: [ ps.hadrian ]);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not familiar with nix, so perhaps this is the second part of the puzzle -- is this the nix-based build script for Hadrian?

Copy link
Collaborator

@alpmestan alpmestan Nov 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It overrides the default haskell packageset by replacing hadrian, etc by the local ones, except for shake for which we specifically require 0.16 from hackage, and same with HUnit 1.3.1.2. Finally, line 19 uses this "new" package set to define a build environment that has a ghc + hadrian and all of its dependencies in it. This is then used along with many other things to provision the entire build environment needed to build ghc, in the rest of the file.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, if the user edits hadrian/UserSettings.hs will the invokation of the build-nix script automatically rebuild Hadrian?

Copy link
Collaborator

@alpmestan alpmestan Nov 17, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. In fact, it will even do it when any file from the hadrian dir changes, but this is a quirk @mpickering told me about and we know how to fix it (it's quite simple, nothing fancy, just requires calling a function or two in the nix code). If @mpickering doesn't get around to doing it in the upcoming days I'll do it.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alpmestan Note that in principle Hadrian should also be rebuilt when the in-tree Cabal library is modified. But this is a rather rare scenario.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is also taken care of correctly but not evident from the script.

Essentially callCabal2nix creates a function which takes all the dependencies of hadrian and returns a recipe to construct hadrian using these dependencies. It then performs some magic to automatically fill in these arguments correctly and because we specify that we want to use the in-tree Cabal on a later line, it passes this version of Cabal as an argument. The key principle of nix is that when an argument changes, then you have to rebuild the result, so when the in-tree Cabal changes, then Cabal and hence hadrian will be rebuilt.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, that's cool!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We got you halfway to using nix haven't we? :)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alpmestan Yes, you have :) I've already heard a lot of good things about nix and I'm tempted!

@snowleopard
Copy link
Owner

/cc @duog who added the build.stack.nix.sh script in #430.

@mpickering
Copy link
Contributor

There are two files.

The first shell.nix can be invoked directly by calling nix-shell shell.nix and its goal is to set up an environment in which you can build ghc. As such, it adds dependencies to the environment such as gmp, python3 and so on. One such dependency is hadrian itself, so the instructions about how to build hadrian are automatically calculated from hadrian.cabal. This happens in the call callCabal2nix which looks in the given directory for a cabal file and creates a nix expression based on that which is can use to build the library.

The second build-nix is a convenient wrapper around this shell.nix which automatically invokes hadrian in the correct environment.

The advantage of this script for nix users is that they don't have to use cabal or stack in order to manage their dependencies, they can just use the normal way they manage dependencies.

Hope that clears things up.

@snowleopard
Copy link
Owner

@mpickering Thanks, could you add this clarification as a comment on top of these scripts? I'm sure I'm not the only one who might be confused by all the different scripts we have. I'll try to add comments to other scripts too.

@duog
Copy link
Contributor

duog commented Nov 17, 2017

@snowleopard: I added build.stack.nix.sh to allow build.stack.sh to not require nix.

@snowleopard
Copy link
Owner

I added build.stack.nix.sh to allow build.stack.sh to not require nix.

@duog Right. Do we need all build-nix, build.stack.sh and build.stack.nix.sh? Sounds a like there may be potential redundancy here...

This adds two new files to the hadrian directory

    shell.nix sets up the build envrionment you need to build ghc
    build-nix is a simple wrapper which invokes hadrian in the correct environment

Note: this patch was authored by @mpickering, however it ended up on phabricator due to the subtree as https://phabricator.haskell.org/D4207.
@mpickering
Copy link
Contributor

I improved the script this evening so that it doesn't rebuild hadrian so often and works with ghc802 as well.

I need to add some comments and non-functional changes tomorrow.

@alpmestan
Copy link
Collaborator

Perhaps we should only keep the default build.sh and build.bat at the top level and create a separate directory called scripts for custom build scripts?

Probably a good idea yes. With a short README that says "use this one if you want to build hadrian using X" for each specific script.

@snowleopard
Copy link
Owner

@alpmestan Indeed, that will work well. I've opened an issue to track this: #475.

@duog
Copy link
Contributor

duog commented Nov 19, 2017

@snowleopard: Yes, it does seem there is redundancy. Unfortunately I don't understand nix, specifically the stack-nix integration, well enough to have an opinion on what should be done. Presumably the nix section in stack.yaml was added to help someone's workflow, we'd need to check with them.

@mpickering
Copy link
Contributor

I added some comments now and renamed the file. Anything else left to do?

@snowleopard snowleopard merged commit 8fd6818 into snowleopard:master Nov 20, 2017
@snowleopard
Copy link
Owner

@mpickering Many thanks, that's great. Merged.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants