-
Notifications
You must be signed in to change notification settings - Fork 710
Use getLocalBuildInfoM not getTestEnv #9726
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
base: master
Are you sure you want to change the base?
Use getLocalBuildInfoM not getTestEnv #9726
Conversation
Thanks @philderbeast, but working around this issue in this particular test doesn't seem to be the right solution. Shouldn't |
If we look at |
I can reproduce this, it seems the issue is when you build the tests with How |
Thanks for taking a look @mpickering.
cabal/cabal-testsuite/src/Test/Cabal/Prelude.hs Lines 99 to 102 in 2acae63
cabal/cabal-testsuite/src/Test/Cabal/Monad.hs Lines 560 to 568 in 2acae63
|
I'm going to park this for now. Feel free to close it if you feel it is the wrong approach. |
Let me take the liberty of turning it into a draft so that next time I do a sweep, I don't panic it's bitrotting. |
99498be
to
ee612a7
Compare
Fixes #9725 using
getLocalBuildInfoM
similar to the way it is done in the following snippet;cabal/cabal-testsuite/PackageTests/ExtraCompilationArtifacts/test.hs
Lines 14 to 19 in 2acae63
The previous
getTestEnv
method was expecting a path that didn't include the ABI hash suffix.When the test runs it logs the library path (unchanged by this fix);
Include the following checklist in your PR: