-
Notifications
You must be signed in to change notification settings - Fork 37
Add ways to build hadrian using nix #473
Add ways to build hadrian using nix #473
Conversation
build-nix
Outdated
@@ -0,0 +1,32 @@ | |||
#!/usr/bin/env nix-shell | |||
#! nix-shell -i bash shell.nix |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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!)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Can we stick to the convention that shell scripts have 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 |
@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 ]); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha, that's cool!
There was a problem hiding this comment.
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? :)
There was a problem hiding this comment.
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!
There are two files. The first The second The advantage of this script for nix users is that they don't have to use Hope that clears things up. |
@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. |
@snowleopard: I added |
@duog Right. Do we need all |
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.
30c028d
to
a228f38
Compare
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. |
Probably a good idea yes. With a short |
@alpmestan Indeed, that will work well. I've opened an issue to track this: #475. |
@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 |
I added some comments now and renamed the file. Anything else left to do? |
@mpickering Many thanks, that's great. Merged. |
This adds two new files to the hadrian directory
Note: this patch was authored by @mpickering, however it ended up on phabricator due to the subtree as https://phabricator.haskell.org/D4207.