Hello there!
My sincerest thanks for developing hix! It's genuinely amongst the most feature-complete devops solutions I've seen that leverage nix (for any language), and I'm surprised more people aren't using it!
From my use of it far, management of projects compiling code for standard host platforms enumerated in haskell.packages is seamless using hix for current GHCs (I especially appreciate the streamlining of cabal management with the declarative interface to hpack!). With that said, I would like to request a feature that would vastly simplify me finalizing an ideal pipeline for a project I'm working on.
My question is if you might be able to expose a toplevel option (ideally a configurable attribute set) for building the alternate cross-compilation backends of GHC built using Hadrian + ghc.nix or by simply importing the derivation ci artifacts (for the new wasm backend) over from ghc-wasm-meta, to be used within an env in lieu of the default flavours of GHC fetched from haskell.packages. Primarily, this is because I'm interested in using the new GHC LLVM/Emscripten-based backends for Java/Webassembly in lieu of the more mature (but ancestral) ghcJs tooling meant to target Reflex-dom and Obsidian that nixpkgs already has pkgsCross-based solvers baked-in for. There are a few reasons for this, but it's largely owing to many of my experiments getting liquid packages to compile within that context being largely fruitless owing to dependency conflicts that (from a day or two of me messing around with overrides) seem incommensurable between the LH versions committed to hackage around the release of GHC 8.10.7 and the obsidian backend.
Hopefully accomodating this doesn't require excessive codebase changes, since this functionality would be a great help to me, unless of course, you have word that the new backends will be mainlined to nixpkgs in the near future.
Hello there!
My sincerest thanks for developing hix! It's genuinely amongst the most feature-complete devops solutions I've seen that leverage nix (for any language), and I'm surprised more people aren't using it!
From my use of it far, management of projects compiling code for standard host platforms enumerated in haskell.packages is seamless using hix for current GHCs (I especially appreciate the streamlining of cabal management with the declarative interface to hpack!). With that said, I would like to request a feature that would vastly simplify me finalizing an ideal pipeline for a project I'm working on.
My question is if you might be able to expose a toplevel option (ideally a configurable attribute set) for building the alternate cross-compilation backends of GHC built using Hadrian + ghc.nix or by simply importing the derivation ci artifacts (for the new wasm backend) over from ghc-wasm-meta, to be used within an env in lieu of the default flavours of GHC fetched from haskell.packages. Primarily, this is because I'm interested in using the new GHC LLVM/Emscripten-based backends for Java/Webassembly in lieu of the more mature (but ancestral) ghcJs tooling meant to target Reflex-dom and Obsidian that nixpkgs already has pkgsCross-based solvers baked-in for. There are a few reasons for this, but it's largely owing to many of my experiments getting liquid packages to compile within that context being largely fruitless owing to dependency conflicts that (from a day or two of me messing around with overrides) seem incommensurable between the LH versions committed to hackage around the release of GHC 8.10.7 and the obsidian backend.
Hopefully accomodating this doesn't require excessive codebase changes, since this functionality would be a great help to me, unless of course, you have word that the new backends will be mainlined to nixpkgs in the near future.