[3.12.0.0] Failed to find the installed unit #10046
Comments
|
Another instance of the same problem at commit 55172e6ab25522853826fc95f4f2e26d2f2d8176 in https://github.com/IntersectMBO/ouroboros-consensus |
|
I have not encountered this again, and no one else has. So let's close this issue. |
|
Saw Cabal-7125 twice today in 3.12.1.0, but the repo I was on is private, so I'm not sure if there's any useful information I can contribute. |
|
I'm pretty sure Cabal-7125 is for failed test-suite, nothing to do with the other error: |
|
I was able to reproduce this error I started seeing again in my code. This is a minimal example: with the following files: Note that |
5 tasks
ulysses4ever
added
cabal-install: nix-local-build
regression in 3.12
and removed
needs triage
labels
|
So, this looks like a regression in 3.12, correct? |
|
@ulysses4ever I think it is indeed a regression. It seems |
|
Thanks for the reproducer @jasagredo. I took a look at this today. It seems that the problem is that |
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Aug 7, 2024
We were passing the flag --coverage-for for every library in the package when building the testsuites. However, if a particular testsuite doesn't depend on one of the packages passed with --coverage-for we would crash. Since we look for the unit ids of all packages given in --coverage-for in the package database (to find hpc artifacts), if the testsuite builds before the library this lookup would fail. The fix is easy: don't pass --coverage-for=<lib> to <testsuite> if <testsuite> doesn't depend on <lib>. If <lib> is an indirect dependency of <testsuite> it'll no longer be covered by HPC, but this is a weird behaviour that I doubt anyone relies on. Fixes haskell#10046
5 tasks
|
Fix in #10250 |
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Aug 7, 2024
We were passing the flag --coverage-for for every library in the package when building the testsuites. However, if a particular testsuite doesn't depend on one of the packages passed with --coverage-for we would crash. Since we look for the unit ids of all packages given in --coverage-for in the package database (to find hpc artifacts), if the testsuite builds before the library this lookup would fail. The fix is easy: don't pass --coverage-for=<lib> to <testsuite> if <testsuite> doesn't depend on <lib>. If <lib> is an indirect dependency of <testsuite> it'll no longer be covered by HPC, but this is a weird behaviour that I doubt anyone relies on. Fixes haskell#10046
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Aug 7, 2024
We were passing the flag --coverage-for for every library in the package when building the testsuites. However, if a particular testsuite doesn't depend on one of the packages passed with --coverage-for we would crash. Since we look for the unit ids of all packages given in --coverage-for in the package database (to find hpc artifacts), if the testsuite builds before the library this lookup would fail. The fix is easy: don't pass --coverage-for=<lib> to <testsuite> if <testsuite> doesn't depend on <lib>. If <lib> is an indirect dependency of <testsuite> it'll no longer be covered by HPC, but this is a weird behaviour that I doubt anyone relies on. Fixes haskell#10046
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Aug 7, 2024
We were passing the flag --coverage-for for every library in the package when building the testsuites. However, if a particular testsuite doesn't depend on one of the packages passed with --coverage-for we would crash. Since we look for the unit ids of all packages given in --coverage-for in the package database (to find hpc artifacts), if the testsuite builds before the library this lookup would fail. The fix is easy: don't pass --coverage-for=<lib> to <testsuite> if <testsuite> doesn't depend on <lib>. If <lib> is an indirect dependency of <testsuite> it'll no longer be covered by HPC, but this is a weird behaviour that I doubt anyone relies on. Fixes haskell#10046
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Aug 7, 2024
We were passing the flag --coverage-for for every library in the package when building the testsuites. However, if a particular testsuite doesn't depend on one of the packages passed with --coverage-for we would crash. Since we look for the unit ids of all packages given in --coverage-for in the package database (to find hpc artifacts), if the testsuite builds before the library this lookup would fail. The fix is easy: don't pass --coverage-for=<lib> to <testsuite> if <testsuite> doesn't depend on <lib>. If <lib> is an indirect dependency of <testsuite> it'll no longer be covered by HPC, but this is a weird behaviour that I doubt anyone relies on. Fixes haskell#10046
alt-romes
added a commit
to alt-romes/cabal
that referenced
this issue
Aug 7, 2024
We were passing the flag --coverage-for for every library in the package when building the testsuites. However, if a particular testsuite doesn't depend on one of the packages passed with --coverage-for we would crash. Since we look for the unit ids of all packages given in --coverage-for in the package database (to find hpc artifacts), if the testsuite builds before the library this lookup would fail. The fix is easy: don't pass --coverage-for=<lib> to <testsuite> if <testsuite> doesn't depend on <lib>. If <lib> is an indirect dependency of <testsuite> it'll no longer be covered by HPC, but this is a weird behaviour that I doubt anyone relies on. Fixes haskell#10046
Mikolaj
pushed a commit
to alt-romes/cabal
that referenced
this issue
Aug 10, 2024
We were passing the flag --coverage-for for every library in the package when building the testsuites. However, if a particular testsuite doesn't depend on one of the packages passed with --coverage-for we would crash. Since we look for the unit ids of all packages given in --coverage-for in the package database (to find hpc artifacts), if the testsuite builds before the library this lookup would fail. The fix is easy: don't pass --coverage-for=<lib> to <testsuite> if <testsuite> doesn't depend on <lib>. If <lib> is an indirect dependency of <testsuite> it'll no longer be covered by HPC, but this is a weird behaviour that I doubt anyone relies on. Fixes haskell#10046
|
We are encountering this issue in the plutus repo, when running |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Building a package with cabal 3.12.0.0, I encountered this error:
Output
A subsequent
cabal build allwas able to find the library and build it, Output collapsed below:Output
To Reproduce
Not sure how to reproduce it. I used the branch https://github.com/IntersectMBO/cardano-node/tree/js/cabal-error-report. I had compiled the project before the latest commit, and then after updating those source-repository-package this error showed up, but it doesn't seem to be deterministic :(
System information
cabal,ghcversions:Additional context
In this same scenario I saw a paraphrasing of the following error (but I lost the terminal output, I will make a proper issue if I see it again, but maybe it is helpful to guess the cause):
A
cabal clean && cabal build allsolved it. Perhapscabal cleanwould not have been needed.The text was updated successfully, but these errors were encountered: