A nice way to run an executable as part of a test suite?

[kindaro]

There is a hack that allows one to make an executable available to the test suite of the same package. I wonder if I may ask for a more direct way to achieve the same. For instance, allow a test suite to depend on an executable (as in #5415) and then, if such dependency is present, build the executable and make it available for the test suite by updating $PATH.

[hvr]

@kindaro What you call "a hack" is the designated way to do this. It's fully documented in the cabal user's guide too. I'm not sure why you call it "a hack" when it's a fully intentional semantics of build-tools.

[kindaro]

@hvr Because this option does not speak of itself as having this semantics, hence I conclude it has such semantics temporarily and accidentally. Your assurance that such use as offered in the linked Stack Overflow answer is intentional and supported is encouraging, but there still remains some criticism to be addressed, specifically:

• It is an unfortunate name. My understanding is that a build tool is a device necessary for building this or that code, such as happy. Clearly this has no relation to an arbitrary executable that I merely want to test, and not at all use as a build tool.

• Nowhere do I read a promise that the executable will remain in $PATH after building the dependent stanza. In particular, even if a tool listed in build-tool-depends is needed for building a test, it may get lost or discarded by the moment the test is being run. Or maybe I am looking at the wrong place in the docs.

I think run-depends is a nice name for an option that specifies the requirement for the dependent-upon executable to be present in $PATH at the time the dependent executable is running.

[gbaz]

Updating the docs to clarify that build-tool-depends is intended to make executables available during test-runtime as running tests is considered part of the build is probably a good idea.

[hvr]

Duplicate of #5411

[hvr]

@kindaro I think what you're suggesting sounds a lot like what #5411 is trying to address

[kindaro]

@hvr If what @gbaz is saying about testing being counted as part of the build process, then I am happy, except for the note that the "tool" part of the name is unfortunate. I think the issue you are referring to is more general and overall about a different problem, that may well happen to never be solved.

[domenkozar]

Clarified in #5561

[domenkozar]

This was clarified in #5561 and #5411 covers the run use-case.