Only choose buildable components for build-depends and build-tool-depends dependencies.

[grayjay]

See #5304 (comment) and #3978 (comment) for an example involving http-client-0.5.12.1. The library stanza contains

  -- See build failure at https://travis-ci.org/snoyberg/http-client/jobs/359573631
  if impl(ghc < 7.10)
    buildable: False

The solver doesn't backtrack to find an older version with a buildable library, and cabal fails with (from #5304 (comment)):

$ cabal new-build -w ghc-7.8.4 --index-state='2018-05-09T06:20:23Z'
Error:
    Dependency on unbuildable library from http-client
    In the stanza 'library'
    In the inplace package 'zzz-0'

This issue is a continuation of #3978, which described a bad error message for an unbuildable component. Its regression test tests the current error message:

cabal/cabal-testsuite/PackageTests/NewBuild/T3978/cabal.out

Lines 1 to 6 in 898fcc2

	# cabal new-build
	Resolving dependencies...
	Error:
	Dependency on unbuildable library from p
	In the stanza 'library'
	In the inplace package 'q-1.0'

This issue should probably be fixed as part of #4087.

[hvr]

@grayjay I'm promoting this issue to high prio as this is effectively causing a lot of install-plans to regress on Hackage currently, and adding a build-depends: base>=4.8 constraint (as @phadej did) to help the solver avoid running into the impl(ghc >= 7.10) buildable:False case unfortunately doesn't work because of a property that @ezyang already diagnosed 2 years ago in the referenced #3978:

when buildable: False we ignore the build-depends. This is desirable for executables but not for libraries.

Would something like ezyang@272b504 constitute a reasonable short-term stopgap solution (assuming that #4087 may take longer to materialise) for improving the situation for this http-client incident?

[phadej]

I made a PR #5332, and it seems to solve my http-client related issue.

[grayjay]

I'm still worried that that commit could prevent cabal from finding a solution in cases where it found a valid solution previously, such as installing a package that provides an executable and an optional, flag-controlled library. I would rather make a safer change, especially if it needs to be applied to the release branch.

I tried implementing my idea from #3988 (comment), which checks whether any of the package's components are buildable in the current environment: https://github.com/grayjay/cabal/tree/issue-5325. I think it would handle the issue with http-client, though I haven't tested it with GHC 7.8.4 yet. Do you think that could work as a short-term solution?

[phadej]

That works even too well: https://github.com/haskell-servant/servant/blob/f88cfd0740be8b2e3085584ee59f20e034168e58/doc/cookbook/jwt-and-basic-auth/jwt-and-basic-auth.cabal#L17
errors with

cabal: Could not resolve dependencies:
[__0] next goal: cookbook-jwt-and-basic-auth (user goal)
[__0] rejecting: cookbook-jwt-and-basic-auth-0.0.1 (not buildable in the
current environment)
[__0] fail (backjumping, conflict set: cookbook-jwt-and-basic-auth)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: cookbook-jwt-and-basic-auth

Without cookbook packages (some of which are !impl(ghc >= 7.10) buildable: False), cabal manages to find an install plan.

---

I agree the use of buildable: False in servant's cookbook is phishy, so maybe it's good it broke.

[phadej]

To be clear: either (my PR or @grayjay's commit) works for me, I have no preference.

[hvr]

I've been dogfooding @phadej's PR a bit yesterday; but I like @grayjay's approach better and I'll dogfood grayjay@238286f today

[hvr]

Btw, @phadej's PR would refuse to build cabal-install, because we have that lib:cabal-install hack in there for CI which is by default (conditional on a manual flag) buildable:False. @grayjay's patch handles this better.

[grayjay]

Thanks for the feedback. I realized that I can also use the component dependency information from #5304 to only reject the package when the component is unbuildable and required by another package. That should allow cabal to handle the cookbook package, as long as nothing depends on it. I'll make a PR.