Skip to content
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

Closed
peti opened this issue Aug 8, 2011 · 4 comments
Closed

Distinguish between extraBuildInputs and propagatedBuildInputs #7

peti opened this issue Aug 8, 2011 · 4 comments

Comments

@peti
Copy link
Member

peti commented Aug 8, 2011

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

  • build-tools (like cpphs, happy) and
  • libraries used in building executable-only projects.
@kosmikus
Copy link
Member

kosmikus commented Aug 8, 2011

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.

@peti
Copy link
Member Author

peti commented Aug 8, 2011

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.

@kosmikus
Copy link
Member

kosmikus commented Aug 8, 2011

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.

@kosmikus kosmikus closed this as completed Aug 8, 2011
@peti
Copy link
Member Author

peti commented Aug 8, 2011

I just saw the commit. Great stuff! Thank you.

sternenseemann pushed a commit that referenced this issue Jul 21, 2022
Use lib instead of stdenv.lib
sternenseemann pushed a commit that referenced this issue Jul 21, 2022
Add a short description to README
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants