In order to use asterius with rules_haskell, I set up (some time ago) a bazel build of asterius that produces a self contained archive (Available here).
This archive contains asterius and needed dependencies (the wasi-sdk fork, dynamic libraries, etc.), so that it can be easily used by rules_haskell both on nixOS and linux bindists.
Now that the new build of asterius was merged into master, the build of this bundle is not up to date. However, I started looking into it and it seems not too far from being usable.
Because of all the progress on the nix part, building the bundle is now way simpler and could run in the CI (provided that the big dependencies are in the cache already, as with the regular nix-build).
It is unclear to me how the nix/cabal build of asterius will evolve, but it may be worth merging the Bazel files that work at the moment to help keep things in sync.
The Bazel files
This PR adds files for building the asterius binaries with bazel in the CI (but not yet the boot process and the generation of the bundle).
The WORKSPACE file sets up external dependencies.
The BUILD.bazel files make their directories bazel packages and contain the definitions of targets to build.
The rest of the files will be in the bazel directory.
Bazel's external dependencies
The bazel/bazel.md file contains the list of external dependencies that should be kept in sync between the bazel build and the cabal one:
The bazel/stack.yaml file should be kept in sync with the nix.cabal.project files as we rely on this custom stack snapshot for external haskell dependencies.
On updating this file, the bazel/stackage_snapshot.json should be generated again by executing bazel run @stackage-unpinned//:pin.
The HASKELL_BINARYEN_COMMIT variable from the WORKSPACE file.
(Because of a rules_haskellissue we do not recover this library through the stack snapshot yet.)
The bazel/nix/bazel_deps.nix file mimics the shell.nix file and exposes necessary attributes to bazel.
If the other nix files are refactored it may be necessary to also modify this one.
In order to use asterius with rules_haskell, I set up (some time ago) a bazel build of asterius that produces a self contained archive (Available here). This archive contains asterius and needed dependencies (the wasi-sdk fork, dynamic libraries, etc.), so that it can be easily used by rules_haskell both on nixOS and linux bindists.
Now that the new build of asterius was merged into master, the build of this bundle is not up to date. However, I started looking into it and it seems not too far from being usable. Because of all the progress on the nix part, building the bundle is now way simpler and could run in the CI (provided that the big dependencies are in the cache already, as with the regular nix-build).
It is unclear to me how the nix/cabal build of asterius will evolve, but it may be worth merging the Bazel files that work at the moment to help keep things in sync.
The Bazel files
This PR adds files for building the asterius binaries with bazel in the CI (but not yet the boot process and the generation of the bundle).
WORKSPACEfile sets up external dependencies.BUILD.bazelfiles make their directories bazel packages and contain the definitions of targets to build.bazeldirectory.Bazel's external dependencies
The
bazel/bazel.mdfile contains the list of external dependencies that should be kept in sync between the bazel build and the cabal one:The
bazel/stack.yamlfile should be kept in sync with thenix.cabal.projectfiles as we rely on this custom stack snapshot for external haskell dependencies. On updating this file, thebazel/stackage_snapshot.jsonshould be generated again by executingbazel run @stackage-unpinned//:pin.The
HASKELL_BINARYEN_COMMITvariable from theWORKSPACEfile. (Because of arules_haskellissue we do not recover this library through the stack snapshot yet.)The bazel/nix/bazel_deps.nix file mimics the
shell.nixfile and exposes necessary attributes to bazel. If the other nix files are refactored it may be necessary to also modify this one.