dependencies are checked even if buildable is False

[bos]

I have a little portion of a .cabal file that looks like this:

executable judy
  main-is: Judy.hs

  buildable: False
  ghc-options: -Wall -rtsopts
  build-depends:
    base == 4.*,
    criterion,
    judy -- DELIBERATELY NOT PRESENT

With cabal-install 1.19.2, I get the following error:

    $ cabal configure
    Resolving dependencies...
*** cabal: Could not resolve dependencies:
    trying: criterion-examples-0 (user goal)
*** next goal: judy (dependency of criterion-examples-0)
    Dependency tree exhaustively searched.

This seems weird and non-intuitive and wrong.

[bos]

Turns out this is an ancient bug, first reported as #224.

[kosmikus]

It's unclear if the old bug is really the same. I've done a quick test, and fixing it in the modular solver itself is nearly trivial. However, cabal-install performs a sanity check on the build plan the solver produces, and omitting the dependencies for non-buildable components from the build plan causes the sanity check to fail. I'm somewhat less familiar with that code, but I'll try to look at it.

Another potential option is to filter out the non-buildable components from the index before even passing the index to the solver, but that seems like a hack.

[TomMD]

Judging by the age, am I correct in assuming no one is working this bug and no solution has been agreed upon? This bug hinders any cross compilation (ios, android, halvm) project. If someone is willing to give a pointer on solution method then I'll look into making a patch and pull request.

[kosmikus]

This had indeed dropped off my radar again. I'm currently travelling, but I'll try to make another attempt next week. Of course, if someone else wants to fix it in the meantime, feel free to do so.

[nh2]

I'm also suffering from this problem. @kosmikus, are you still interested in working on it?

[snoyberg]

I just got bit by this too. (Thanks @23Skidoo for so quickly pointing out that it was a dupe.) However, I think the "solver" label is not correct: using runghc Setup.hs configure can trigger this behavior too.

[mietek]

Another way to reproduce this bug:

cabal install -v3 --dry-run cheapskate-0.1.0.4

This shouldn’t pull in wai or wai-extra, as they’re dependencies for cheapskate-dingus, which isn’t buildable by default.

[dcoutts]

There's a little bit of history to this one. We had a patch (for the Cabal lib) to try to avoid non-buildable packages contributing to deps but doing so broke things in subtle ways and we had to revert it. I can't remember the details off the top of my head. The patch should be there in the git history if you look for "buildable".

[ntc2]

Me too.

[phadej]

The commit @dcoutts mentioned: 04dff51

[hvr]

am I right, that the current backward compat workaround is to use a manual flag, e.g.

flag build_judy
  manual: True
  default: False

executable judy
  main-is: Judy.hs

  if !flag(build_judy)
    buildable: False
  ghc-options: -Wall -rtsopts
  if flag(build_judy)
    build-depends:
      base == 4.*,
      criterion,
      judy -- DELIBERATELY NOT PRESENT

?

[ntc2]

@hvr: I think the important thing in your example is that you guarded the build-depends with the if flag(build_judy). That works! And it still works if I remove the manual: True on the flag. THANKS!

Complete example that actually builds:

name: needs-judy
version: 0
build-type: Simple
cabal-version: >= 1.2

flag build_judy
  default: False

library

executable judy
  main-is: Judy.hs

  ghc-options: -Wall -rtsopts
  if flag(build_judy)
    build-depends:
      -- DELIBERATELY NOT PRESENT
      judy
  else
    buildable: False

assuming a default Setup.hs containing:

import Distribution.Simple
main = defaultMain

[kosmikus]

The workaround that @hvr provides should indeed be ok.

I've also been working on this. Pull request (not very thoroughly tested) will follow in a few minutes.

[ezyang]

The change (that got reverted) is a0ca303

To state it more clearly, the bug is that when we flatten the package description, the set of package-global dependencies we compute blindly gobbles up all of the build-depends, regardless of the status of the buildable flag. I don't know what the subtle problem could be.

[grayjay]

This was fixed in #3039.