Only choose buildable components for build-depends and build-tool-depends dependencies. #5325
Comments
|
@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
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 |
|
I made a PR #5332, and it seems to solve my |
This commit handles the most common case of issue haskell#5325 by checking that each package is buildable in the current environment. The solver replaces non-buildable packages with failure nodes. It allows two types of buildable packages: Buildable non-test package: The package has at least one buildable library or executable. Buildable test package: The package has no libraries or executables, but it does have at least one buildable test or benchmark. The buildable check can give false-positives, because it ignores all flags, and it doesn't check whether the intra-package dependencies of a component are buildable. The check is also incomplete because it is performed before any flags are assigned. It is possible for the solver to later choose a value for a flag that makes the package unbuildable.
|
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? |
|
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 Without cookbook packages (some of which are I agree the use of |
|
To be clear: either (my PR or @grayjay's commit) works for me, I have no preference. |
|
I've been dogfooding @phadej's PR a bit yesterday; but I like @grayjay's approach better and I'll dogfood grayjay@238286f today |
…ment. This commit handles the most common case of issue haskell#5325 by checking that each component that is required as a dependency is buildable in the current environment, where environment refers to the compiler, os, arch, and global flag constraints. The solver records whether each component is buildable in the package's PInfo. The buildable check can give false-positives, because it only considers flags that are set by unqualified flag constraints, and it doesn't check whether the intra-package dependencies of a component are buildable. The check is also incomplete because it is performed before any automatic flags are assigned. It is possible for the solver to later choose a value for a flag that makes the package unbuildable.
…ment. This commit handles the most common case of issue haskell#5325 by checking that each component that is required as a dependency is buildable in the current environment, where environment refers to the compiler, os, arch, and global flag constraints. The solver records whether each component is buildable in the package's PInfo during index conversion. Then it checks that each required component is buildable in the validation phase, similar to the check for missing components. The buildable check can give false-positives, because it only considers flags that are set by unqualified flag constraints, and it doesn't check whether the intra-package dependencies of a component are buildable. The check is also incomplete because it is performed before any automatic flags are assigned. It is possible for the solver to later choose a value for a flag that makes the package unbuildable.
|
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. |
…ment. This commit handles the most common case of issue #5325 by checking that each component that is required as a dependency is buildable in the current environment, where environment refers to the compiler, os, arch, and global flag constraints. The solver records whether each component is buildable in the package's PInfo during index conversion. Then it checks that each required component is buildable in the validation phase, similar to the check for missing components. The buildable check can give false-positives, because it only considers flags that are set by unqualified flag constraints, and it doesn't check whether the intra-package dependencies of a component are buildable. The check is also incomplete because it is performed before any automatic flags are assigned. It is possible for the solver to later choose a value for a flag that makes the package unbuildable.
…ment. This commit handles the most common case of issue #5325 by checking that each component that is required as a dependency is buildable in the current environment, where environment refers to the compiler, os, arch, and global flag constraints. The solver records whether each component is buildable in the package's PInfo during index conversion. Then it checks that each required component is buildable in the validation phase, similar to the check for missing components. The buildable check can give false-positives, because it only considers flags that are set by unqualified flag constraints, and it doesn't check whether the intra-package dependencies of a component are buildable. The check is also incomplete because it is performed before any automatic flags are assigned. It is possible for the solver to later choose a value for a flag that makes the package unbuildable. (cherry picked from commit b747032)
|
Current status:
|
andreasabel
added
the
re: build-tool
See #5304 (comment) and #3978 (comment) for an example involving
http-client-0.5.12.1. The library stanza containsThe solver doesn't backtrack to find an older version with a buildable library, and cabal fails with (from #5304 (comment)):
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
This issue should probably be fixed as part of #4087.
The text was updated successfully, but these errors were encountered: