Support for setup-tool-depends

[hvr]

I just ran into a case in google/proto-lens#110 (comment) which requires us to specify a build-tool-depend-style dependency for custom-setup, as Setup.hs needs to be able to execute the proto-lens-protoc tool provided by the proto-lens-protoc package.

I originally mistook #4047 for providing this feature, but then I realized this is subtly different (because #4047 is about replacing Setup.hs with an externally provided executable, while this is merely about the ability to specify dependencies on exe components); so we'd like to say something like

custom-setup
  setup-depends: base >= 4.8 && < 4.11, proto-lens-protoc == 0.2.*
  setup-tool-depends: proto-lens-protoc:proto-lens-protoc == 0.2.*

-- Setup.hs
import Data.ProtoLens.Setup -- from lib:proto-lens-protoc

-- executes proto-lens-protoc:exe:proto-lens-protoc
main :: IO ()
main = defaultMainGeneratingProtos "tests" 

---

PS: it appears that build-tool-depends in non-setup stanzas makes an executable available to Setup.hs via $PATH, even though that wasn't obvious to me from the log-output, as the last environment-dump before setup is executed didn't show it in the $PATH. So it seems the environment dumped only applied to the ghc --make Setup.hs invocation, but the setup invocation used a different not-shown environment.

However, this also means we can actually fake #4047 already now with a trivial Setup.hs (which needs at most base and process) which merely re-executes an external executable imported via build-tool-depends

[ezyang]

The current guidance is that you should make a setup-helper package which has the build-tools dependency, so that the setup stanza stay simple. Does that work here?

[hvr]

@ezyang but if you run library code living in a setup-helper package (and the setup-helper package depending on some executable), how does cabal know that it needs to propagate the build-tool-depends $PATH entry to your local setup stanza? Afaik, build-tool-depends need to be private to the package that specifies it.

[ezyang]

Yeah, the crux of the matter is we need some sort of "runtime" tool-depends for this pattern to work. I feel like we had a ticket for this but I don't know where it is.

[hvr]

@ezyang are you referring to the discussion in #4104 (comment) ?

[ezyang]

That seems like a pretty good comment :)

[Ericson2314]

I put up a more general alternative here: #5411

[khumba]

PS: it appears that build-tool-depends in non-setup stanzas makes an executable available to Setup.hs via $PATH, even though that wasn't obvious to me from the log-output, as the last environment-dump before setup is executed didn't show it in the $PATH. So it seems the environment dumped only applied to the ghc --make Setup.hs invocation, but the setup invocation used a different not-shown environment.

However, this also means we can actually fake #4047 already now with a trivial Setup.hs (which needs at most base and process) which merely re-executes an external executable imported via build-tool-depends

A caveat here, at least with Cabal 2.4, PATH is only set correctly if performing per-component builds. For example with Qtah, qtah-cpp's Setup.hs needs a binary from qtah-generator, both use Custom builds, and what gets added to PATH is

PATH=.../dist-newstyle/build/x86_64-linux/ghc-8.6.5/qtah-generator-0.7.1/build:...

whereas the executable exists at

.../dist-newstyle/build/x86_64-linux/ghc-8.6.5/qtah-generator-0.7.1/build/qtah-generator/qtah-generator

, there's an extra subdirectory there.