I doubt that bootstrapping GHC from source is actually possible at this point without a year or two of dedicated work. What you can theoretically do is compile GHC using the C backend and then use gcc to build a bootstrap GHC from the generated C – but at that point you can already use the binary GHCs since no one is going to audit that.
2 Likes
meta = {
broken =
with stdenv.hostPlatform;
if isX86_64 && (isLinux || isDarwin)
then "no one's had success fixing it"
if isAarch64 && isDarwin
then "upstream hasn't addressed compatibility issues yet"
else false;
}
Note the use of the hostPlatform.isXX predicates. Compared to string-comparison against builtins.currentSystem-type doubles, the predicates are much more readable and don’t encourage bogus assumptions (like "everything that isn’t x86_64-linux or aarch64-linux is some kind of Darwin).
2 Likes
This is also how Nix parses it: or has higher precedence than !=.
It looks a little funny because or requires whitespace, so you can write it even more misleadingly like this:
pkg.meta.broken or false!=false
but in fact Nix parses it as
(pkg.meta.broken or false) != false
If you think about it, this makes more sense. Most of the time, the thing after the or is going to be a literal (as it is here) or an identifier. So having or have higher precedence will save parentheses more often than it forces them to be added.
The Nix grammar is full of careful decisions like this; clearly somebody paid a lot of attention to usability. Almost makes me willing to forgive the mandatory semicolons 
1 Like
Hey, thanks for your reply.
Just to be clear, my complaint was not about haskellPackages.ghc8107Binary. Every compiler that is written in the language it compiles for needs a binary seed (for C/C++ this is bootstrap-files).
I swear that at some point during my struggle, nix-env -iA for one of these tools (I thought it was cabal but now I’m not sure anymore) printed out some message like
downloading and installing GHC 9.0.X
this will be installed privately and will not interfere with the system installation
…or something like that. And it was very obvious that whatever it was downloading was not based on the nixpkgs ghc8107Binary bootstrapping chain. Unfortunately I’m having a hard time what led to the message. It was the last thing I tried before getting frustrated enough to set the project aside for a bit.
Yeah, it is also incredibly complex! I tried it and could not get it working. It kept trying to download some tarball-snapshot of nixpkgs, instead of using $NIX_PATH, which was not a good sign.
Fortunately I am very, very close to getting a cabal2nix-based build of purescript working. I really like cabal2nix; it’s simple and it just works, it has nix drive the build process (and invoke ghc) rather than some language-specific build tool, and it produces readable nix expressions that accept overrides.
I don’t know why cabal2nix declares itself deprecated, it’s really too bad. It and crate2nix look like the perfect examples of how nix ought to deal with language-specific package registries (which, let’s face it, are so trendy right now that we can’t keep trying to ignore them). It gives the package maintainers something that is good enough to commit verbatim probably ~80% of the time, and in the rest of the cases it’s a nice clean guaranteed-to-build starting point for manual intervention.
Together, I think these roughly underscore the point of my almost-but-not-quite-rhetorical question, which was roughly: if we’re going to fiddle with the type and form of the variable, we’d might as well make it easy to compose these without complex conditionals that are going to be easy to introduce bugs into (especially if we add more platforms, like other BSDs or Windows?)
That said, this point is worth wrestling with:
I think the string comparison part of this roughly has me, but I think I’m still on the fence on whether nested conditionals against a complex matrix of qualities will be much better?
I’m not sure I understand what alternative you are proposing. Could you be more concrete?
Keep in mind that nix has no static type system whatsoever. It also lacks statically resolvable identifiers. Things like enums and algebraic datatypes help prevent mistakes in other languages; trying to simulate them in Nix actually encourages mistakes.
Please be careful not to kill this effort with overengineering.
There is a close parallel here to RFC 89, which started out as a nice simple “add a meta boolean to indicate packages that download binaries”. A lot of bikeshedding happened, and what’s been approved is stuck with a bunch of complexity that none of the people active in the PR are particularly excited about, and now the PR appears to be languishing somewhat.
Oh, that already happened. Quite a while ago too. There are already predicates for both of those, and much more, including 8-bit AVR (!).
lib/systems is a bit of a hairball, but lib/systems/inspect.nix is one part of it that is nice and clean and works. Each predicate describes some subset of the platforms (both present and future) nixpkgs might be used with. If you can describe your needs with those predicates, do so. &&, ||, and ! correspond to set intersection, union, and complement. If you can’t, add a new predicate. When new platforms are added one of the duties of the person adding the platform is to go through the list of predicates and make sure they react properly to the newly-added platform – like I did when I added mips64el.
In that sense, lib/systems/inspect.nix is the present/future “rendezvous point” between the set of enabled platforms and packages that wish to query that set.
1 Like
Am I allowed to pose the question without having the answer?
Yes–I know. I’m talking about adding more platforms to the conditionals.
And every time one of the predicates changes, there’s a chance they’re breaking the (often incorrect) assumptions underlying many existing conditionals. The semantic drift it forces is hard to ferret out after the fact unless the committer left a very good paper trail. The explanations will only help with this when the explanation and conditional meet the author’s expectations–otherwise they’ll just mislead.
I’m not sure this formulation leaves me room to do anything but capitulate, so I’m going to go ahead and disengage from the thread.
Does it? cabal2nix is the essential tool, which we use to create all Haskell packages in nixpkgs and there are no plans to change that. Also there is active development on cabal2nix going on, although not very intensive.
The haskell.nix project has a very different scope and is currently very unsuited and not intended for replacing cabal2nix.
1 Like
You are correct.
Sorry, I got stack2nix (which is the one whose README.md says “Deprecated in favor of GitHub - input-output-hk/haskell.nix: Alternative Haskell Infrastructure for Nixpkgs”) mixed up with cabal2nix. I make the same mistake with crate2nix and cargo2nix, which are even more similarly named.
In any event, cabal2nix is definitely the one with all the awesomeness. I hope the rust-ecosystem tool that tries to emulate it (which I think is crate2nix) replaces importCargoLock as soon as policy allows it to.
1 Like
Not any more
3 Likes