accelerate
accelerate copied to clipboard
AccelerateHS
Add nix support: building, testing, provisioning devShells
Description
I want to provide an easy to use and high level interface for developing and using this library that works in a sandboxed and reproducible way, that's why I'm trying to nixify accelerate. In the same run I also want to do some maintenance tasks that I think will be easier as soon as everything is working with nix
- [x] upgrade stack snapshots
- [x] make everything build with cabal additionally to the current stack infra
- [x] provide nix tools that can be imported by other accelerate* projects to make nixification trivial
This was easily the hardest project I ever nixified
How has this been tested?
nix flake check -Lv --impure should test all relevant attributes.
Some combinations may fail. However, I wanted to avoid to add a ton of patches to make all of the things build, mainly because maintenance will be much harder.
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist
- [x] My change requires a change to the documentation
- [x] My code follows the code style of this project
- [x] I have updated the documentation accordingly
- [x] I have added tests to cover my changes
- [x] All new and existing tests passed
GHC 94 has landed in stack and haskell.nix, so I can pick up development here again.
Can you update the nix build process to work with current master and add a nix section to the CI?
Additionally, skimming through I see a bunch of ancillary stuff to do with HLS, cabal-fmt, ourmolu, etc. Is that actually necessary? I also see references to a pre-commit-hook that isn't included, and you've committed a .lock file which I don't think should be here, etc.
It might be easier to close this PR and start again rather than rebasing and removing the unnecessary cruft.
Thank you. I have been working on this locally and have simplified it a bit. Which of the lock files would you like to not be commited?
If you mean the flake lock, it needs to be commited. Otherwise the build will not be reproducible.
it came as a surprise to me that you removed support for so many ghc versions :D
More GHC versions are still supported and tested with the CI, I just removed all the extra stack-*.yaml files (it has been a mess and stack is getting more difficult to work with...)
just removed all the extra stack-*.yaml files
my nix code basically uses the stack yaml as source of truth, so I will have to remove compat for older ghc versions.
This is now almost complete, only thing missing is I think a wrapper for stack to use it more conveniently in the devShell