-
-
Notifications
You must be signed in to change notification settings - Fork 154
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
Distinguish between extraBuildInputs and propagatedBuildInputs #7
Comments
The first bullet is done already. Build-tools are listed as extraBuildInputs. True about the second. I'm wondering if in the interest of readability we should integrate this logic in cabal.nix. It'd be somewhat nicer to just have "libraryDepends", "hackageDepends", "buildTools" fields, and a "mode" field which can be "executable", "library" or both and have cabal.nix do the right thing. |
Yes, I believe that is a good idea. That would make Nix expressions look more like the Cabal file itself, and IMHO that makes them more accessible (and appealing) to Haskell programmers that don't know much about Nix. |
This is done. I've tried hard to be backwards-compatible. So ideally, the old style is still supported. And even if the new style is used, the hashes should in general be unchanged. |
I just saw the commit. Great stuff! Thank you. |
Use lib instead of stdenv.lib
Add a short description to README
Right now, everythings that's mentioned in the Cabal file becomes a propagatedBuildInput. There are dependencies, however, that don't need to be propagated, namely
The text was updated successfully, but these errors were encountered: