Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kindaro opened this issue Jul 8, 2018 · 8 comments
Closed

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

kindaro opened this issue Jul 8, 2018 · 8 comments

Comments

@kindaro
Copy link

kindaro commented Jul 8, 2018

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
Copy link
Member

hvr commented Jul 8, 2018

@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
Copy link
Author

kindaro commented Jul 8, 2018

@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
Copy link
Collaborator

gbaz commented Jul 8, 2018

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
Copy link
Member

hvr commented Jul 8, 2018

Duplicate of #5411

@hvr hvr marked this as a duplicate of #5411 Jul 8, 2018
@hvr
Copy link
Member

hvr commented Jul 8, 2018

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

@kindaro
Copy link
Author

kindaro commented Sep 2, 2018

@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
Copy link
Collaborator

Clarified in #5561

@domenkozar
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants