Rework Nix system

[jaschutte]

Removed all 'old-style' Nix infrastructure in favor of nix flakes.

This makes all the Nix logic easier to understand whilst also making it easier to include this within other projects.

The only downside is that you can no longer use old nix syntax, but considering clash-compiler doesn't support that, I don't see why clash-protocols should.

[martijnbastiaan]

Stupid question, but why does it build clash-protocols in a nix shell? I thought that was supposed to give you an environment where you could start developing for the repo you're in.

[jaschutte]

Not at all! It's actually misleading naming, it doesn't build clash-protocols itself. In shellFor the packages attribute is a list of packages you plan to build. As I understand, you have to mention the package you want to build within the packages attribute so Nix can know which dependencies it should expose to cabal. So it will build all dependencies of clash-protocols (so it can give those to cabal), but not clash-protocols itself.

Note: this is specific to the shellFor, the standard mkShell packages does not do the same!
Thanks Nix...

[rowanG077]

mkShell does have a similar thing. You can add packages to the inputsFrom attribute. Which essentially does what you describe as well.

[martijnbastiaan]

Nice. Can I merge @jaschutte ?

[DigitalBrains1]

Is aarch64-reloc.patch no longer needed in some form?

Here was where it was applied. Press the nix/nixpkgs.nix Load diff text to actually open the file so the link leads somewhere.

[rowanG077]

That patch should no longer be needed since it's upstream in GHC 9.10

Edit: Actually that's not true. It's in a backport for GHC 9.10.2 but anything before that does not include that commit. So it indeed should remain.

[DigitalBrains1]

Per Rowan's comment, the patch for aarch64 should remain

[edit] Or GHC upgraded from current 9.10.1 to 9.10.2 [/edit]

[jaschutte]

I have reapplied the patches, although I can't test it myself as I do not have an aarch64-linux device. Could @rowanG077 test if it properly applies?

If it does, I think this is good to merge

[jaschutte]

I do wonder why the patches are applied here though instead of directly at clash-compiler, surely if it's a bug with GHC it would happen to all clash projects right and not just clash-protocols? So why are the patches being applied only here?

[DigitalBrains1]

I do wonder why the patches are applied here though instead of directly at clash-compiler, surely if it's a bug with GHC it would happen to all clash projects right and not just clash-protocols? So why are the patches being applied only here?

Excellent question! The answer might be that Rowan critically needed it to continue what he was working on. But if you can actually make this part of the Nix flake in the clash-compiler repo and have it affect downstream uses like clash-protocols, that sounds like a good improvement! I requested it to be retained here to not introduce an actual regression, it's not that I oppose better solutions :-).

[DigitalBrains1]

Rowan, I agree with James that it'd be best if someone actually tested whether the aarch64 patching Nix code truly accomplishes its task. Could you test it on an aarch64-linux system? Alternatively, I suppose I could use QEMU to spin up a VM with an emulated processor, if you currently have no time to spend on this.

[DigitalBrains1]

I think this should be squash-merged, with the commit message of the first commit as the final commit message. You could make this more explicit by squashing the commits before merge (but we'll still use a squash merge as there is a difference between a squash merge and a normal merge of a single commit, and we like to use the former).