-
Notifications
You must be signed in to change notification settings - Fork 711
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
Comments
@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 |
@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:
I think |
Updating the docs to clarify that |
Duplicate of #5411 |
@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. |
Clarified in #5561 |
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
.The text was updated successfully, but these errors were encountered: