build-tool-depends silently ignored for non-existent executable

[hvr]

Consider the following specification,

name:                dummypkg
version:             0
build-type:          Simple
cabal-version:       >=2.0

library
  default-language: Haskell2010
  build-tool-depends: mtl:imaginary-exe

when invoking new-build, this silently succeeds. And also, plan.json doesn't record any exe-depends from dummypkg-0-inplace on mtl as it would if build-tool-depends referred to an actually existing executable:

    {
      "type": "configured",
      "id": "dummypkg-0-inplace",
      "pkg-name": "dummypkg",
      "pkg-version": "0",
      "flags": {},
      "style": "local",
      "dist-dir": ".../dist-newstyle/build/x86_64-linux/ghc-8.2.1/dummypkg-0",
      "depends": [],
      "exe-depends": [],
      "component-name": "lib"
    },

For a build-tool-depends declaration, I'd expect the solver to require the existence of that executable in the respective package as a constraint to solve for. The reason being is that packages may start out as a library, and in later releases start adding an executable. Or sometimes executables may get renamed or removed.

/cc @grayjay @Ericson2314

[grayjay]

It looks like cabal doesn't solve for specific executables yet:

cabal/cabal-install/Distribution/Solver/Modular/IndexConversion.hs

Lines 374 to 376 in d53b6e0

	-- TODO do something about the name of the exe component itself
	convExeDep :: DependencyReason PN -> ExeDependency -> LDep PN
	convExeDep dr (ExeDependency pn _ vr) = LDep dr $ Dep (IsExe True) pn (Constrained vr)

That will probably require #4087.

[Ericson2314]

@grayjay yeah that was a stop-gap in lieu of per-component solving. Is a better solution possible now?

[phadej]

Can we make specific constraints, including only versions of package with an executable requested. That should work even we don't have per-component solving

[Ericson2314]

That would be nice. To be clear, this still fails on the Cabal library side of things, right? I added a bunch of tests and stuff for those failure cases.

[grayjay]

@Ericson2314 I don't know of a better solution now.

@phadej Where would the constraints be specified? It seems like that would be easier to implement than complete per-component dependency solving.

[phadej]

@grayjay when the build-tool-depends executable is requested, we could elaborate that into more precise constraints than just package (+ bounds). I don't know how it happens now though :(

[grayjay]

I think that would need to happen in the solver, after it chooses to build a package that has a build-tool-depends dependency. That corresponds to the first tree transformation that I described under "Component dependency validation steps" in #4087 (comment). I don't think we need to add the other tree transformations as long as we continue to require the dependencies for all executables for each package.