The "benchmark" target dependencies conflict with "executable" targets

[nikita-volkov]

I have a package with the following structure:

library
  ...
executable measure-memory
  ...
  build-depends:
    ghc-datasize,
    ...
benchmark benchmarks
  ...
  build-depends:
    criterion == 0.8.*,
    ...

The criterion == 0.8.* dependency conflicts with ghc-datasize and its impossible to compile having those two together. The issue with Cabal however is that neither the benchmark or library target has ghc-datasize in dependencies, yet Cabal still considers it and does not allow me to compile the benchmark target. When I remove the executable target, the compilation goes fine.

I'm on

$ cabal --version
cabal-install version 1.19.2
using version 1.19.2 of the Cabal library 

[tibbe]

/cc @kosmikus

This is a limitation of the dependency solver and it bites us in a bunch of different situations. :(

Another example of when it bites us is when a cycle is created because a dependency of a test suite in turn depends on the main library. This happens in all core packages that are used by e.g. test-framework or criterion.

[nikita-volkov]

BTW, I've just checked and the problem remains even when I change the target from benchmark benchmarks to executable benchmarks. So it looks like the issue is that it shares dependencies across all executables and benchmarks.

[tibbe]

Yes, the issue is that the whole package is considered as a unit for dependency resolution.

[kosmikus]

@tibbe You've said repeatedly that this is a solver shortcoming, but I don't see the solver as the main culprit. Can we build individual components of packages out of order? If yes, I'm happy to try to make the necessary solver changes.

[tibbe]

@kosmikus Yes, I think we can and should consider each section (i.e. the lib, exes, test suites, and benchmarks) as separate units, with their own constraints, to build.

[23Skidoo]

Cabal has an internal component dependency graph. This information needs to be communicated to the solver.

[23Skidoo]

Closing as a duplicate of #1575.