Skip to content

Different executable components using the same build plan #3732

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

Open
jaccokrijnen opened this issue Aug 29, 2016 · 4 comments
Open

Different executable components using the same build plan #3732

jaccokrijnen opened this issue Aug 29, 2016 · 4 comments

Comments

@jaccokrijnen
Copy link
Contributor

I have this cabal file

name: test-components
version: 0.0.1
cabal-version: 1.12
build-type: Simple
license: AllRightsReserved
description:


executable component-a
    main-is: Main.hs
    build-depends:
        base -any
    default-language: Haskell2010
    hs-source-dirs: src

executable component-b
    main-is: Main.hs
    build-depends:
        base == 42.*
    default-language: Haskell2010
    hs-source-dirs: src

test-suite component-c
    type: exitcode-stdio-1.0
    main-is: Main.hs
    build-depends:
        base == 42.*
    default-language: Haskell2010
    hs-source-dirs: src

And run cabal new-build exe:component-a. Then I get this message:

Resolving dependencies...
cabal: Could not resolve dependencies:
trying: test-components-0.0.1 (user goal)
next goal: base (dependency of test-components-0.0.1)
rejecting: base-4.8.2.0/installed-0d6... (conflict: test-components =>
base==42.*)
rejecting: ...

Is this expected behaviour? I'd expect that build-plans for components are seperate. When I remove component-b and keep component-c with the same incorrect dependency I get no error (test-suite have a different status?).

The actual problem I ran into was two components that required different versions of a certain dependency and therefore dependencies could not be resolved.

@ezyang
Copy link
Contributor

ezyang commented Aug 29, 2016

I think this is this bug #1575? We're so close to fixing it, but it requires some extra changes to the solver :/

@jaccokrijnen
Copy link
Contributor Author

Ok, awesome, I missed that.

@ezyang
Copy link
Contributor

ezyang commented Sep 11, 2016

#1575 took a different direction so I'm reopening this.

@ezyang ezyang reopened this Sep 11, 2016
@ezyang
Copy link
Contributor

ezyang commented Sep 11, 2016

CC @hvr

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

3 participants