Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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.

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

No branches or pull requests

4 participants