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

Cabal 2's internal libraries don't work with HEAD #3361

Closed
bucklereed opened this issue Aug 17, 2017 · 3 comments
Closed

Cabal 2's internal libraries don't work with HEAD #3361

bucklereed opened this issue Aug 17, 2017 · 3 comments

Comments

@bucklereed
Copy link

Cabal 2 support has just landed in HEAD with #3288 (hurrah), but one of the shiny new features doesn't work with stack yet: internal libraries (introduced in haskell/cabal#3022). A short demonstration:

$ cat internal-library-test.cabal 
name: internal-library-test
version: 1
cabal-version: >= 1.24

library internal-library-test-lib
  exposed-modules: Foo
  default-language: Haskell2010

executable exe
  main-is: Main.hs
  default-language: Haskell2010
  build-depends: internal-library-test-lib
$ cat stack.yaml 
resolver: lts-9.1
packages: ['.']
$ stack build

Error: While constructing the build plan, the following exceptions were encountered:

In the dependencies for internal-library-test-1:
    internal-library-test-lib must match -any, but the stack configuration has no specified version
needed since internal-library-test-1 is a build target.

Plan construction failed.
$ stack --version
Version 1.5.1, Git revision aa5003a153504f54051e42a844a0c1c3d7f82163 i386 hpack-0.17.1

I think that this ought to work as-is (that is, without anything internal-library-specific in stack.yaml), but it wouldn't be a disaster if it needed some magical incantation.

@snoyberg
Copy link
Contributor

Not certain, but: it seems like a simple workaround for this may be that, during the cabal file parsing step, to simply remove any build-depends referring to an internal library. I'm not sure if Cabal will then handle the build correctly from that point, but it's worth a shot.

snoyberg added a commit that referenced this issue Sep 13, 2017
This should resolve both #3364 and #3361. There is a test case included
that should address both of them as well.

This is still relatively hacky. We will eventually be overhauling the
component system more dramatically to support Backpack with #2540 (CC
@ezyang).

This may still have some problems due to the upstream issue
haskell/cabal#4763, but at least in theory we're matching the behavior
of upstream. We can consider workarounds after that issue comes to a
conclusion.
@snoyberg
Copy link
Contributor

This should be resolved by #3430. It would be great if you could test that branch before this gets merged to master.

@decentral1se
Copy link
Member

Closing this one off - please re-open if #3430 doesn't solve it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants