-
-
Notifications
You must be signed in to change notification settings - Fork 153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OS conditionals and flags in general #217
Comments
https://github.com/NixOS/cabal2nix/blob/master/doc/00-future-of-haskell-packaging-in-nixpkgs.md describes our plans for the future. The item https://github.com/NixOS/cabal2nix/blob/master/doc/03-map-cabal-files-to-nix-without-information-loss.md seems particularly relevant for your question. |
This is excellent, thank you! I had been thinking that a relatively easy, low-impact option would be to generate per-platform derivations when an They're also a bit tricky to convert to Nix for two main reasons:
The latter point is why I started thinking about per-platform derivations as we could then just ask for the cumulative options for each supported platform and let the |
The newly introduced |
I didn't find reference to this issue, so I wanted to ask it as broadly as possible: is there an intention to better support cabal flags such as compiler version conditionals, but particularly operating system conditionals?
As things stand, the generated Nix is very Linux-centric. To accommodate the switching logic expressible in the Cabal language would mean some burden on existing Linux users in the form of more complex Nix expressions that replicate that logic. In my
cabbage
tool, for instance, there is support for dealing withframework
dependencies needed on OS X. With the nixpkgs Haskell infrastructure, these can be shoe-horned intobuildInputs
so that they are propagated, but it requires per-package reconfiguration. There are additionally changes to the other dependency fields depending on the platform (e.g. theOpenGL
framework on OS X vs.mesa
on Linux).I can make PRs to fix this for darwin users on a case-by-case basis in
configuration-common.nix
as I encounter problems, or the configuration logic can be pushed down into the derivations themselves. Do the Haskell infrastructure maintainers have an opinion on this?The text was updated successfully, but these errors were encountered: