Builds depending on cpphs fail occasionally. #5379
Comments
|
Does, e.g., using 8.2.2 in a clean build and then rebuilding with 8.2.2 always work?
|
|
Here is the verbose output: It still fails if I run |
|
I have a guess here. I suspect that it recognizes the library dependency on cpphs as a tool dependency instead (c.f. ).It then determines that the program exists, but then omits to check that the library exists for use with the particular compiler configuration. I think this is a rare issue that we haven't seen before because people tend to depend on the executable and not the library, and so the "clever" hack that correctly turns the library into a |
|
I've been trying to reproduce this locally, but so far I haven't had any luck
I don't understand what you mean, can you point to the code that implements this logic? afaik if you Also note there's quite a few packages combining executables & libraries where users typically want the library component (where the executables are just relatively uninteresting CLI frontends or test programs). And we haven't observed issues of this kind there yet. I also don't see how
can interact with with build-plans for other GHC versions, as each GHC version has its own nix-style store which are isolated from each other. I.e. whatever the store for GHC 8.4.3 cached cannot have any influence on a build process for say GHC 8.0.2. |
|
I am still unsure as to why the global package state gets into an inconsistent state, but building If it helps, some of my builds have failed for this reason on the matrix CI in the past (including shake-literate). |
|
@hvr yeah i think my theory isn't exactly right. rereading the code I linked I think I misread one instance of At least that gives one approach to try to narrow down to a smaller repro. |
|
@vmchale I have a suspicion that your nix-style store got into an inconsistent state (in the sense of #5125), thus I'd suspect that you have a folder |
|
I was able to reproduce this myself now; there appears to be a subtle bug in new-build's logic which can be reproduced as follows: Start with an empty run Notice how the build-plan mentions only but also which means that After this procedure, we end up with the situation that a folder gets populated with library and executable component, however it doesn't get registered via If we had used In summary, the bug is exposed if the following conditions are simultaneously satisfied:
...then the store cache entry is fully populated but but its library component fails to be registered! (this leaves the cache in an inconsistent state, as the invariant that each cached unit (i.e. for which a folder was created and populated) must have its library component (if it contains any) registered via |
|
/cc @dcoutts |
As the case of `cpphs-1.20.8` has shown in haskell#5379, in cases when a monolithic package gets installed due to its executable components (i.e. `exe:cpphs`) into the store we *have* to register if there's a buildable public library (i.e. `lib:cpphs`) that was built and installed into the same store folder as otherwise this will cause build failures once a target actually depends on `lib:cpphs` This ought to fix haskell#5379
As the case of `cpphs-1.20.8` has shown in haskell#5379, in cases when a monolithic package gets installed due to its executable components (i.e. `exe:cpphs`) into the store we *have* to register if there's a buildable public library (i.e. `lib:cpphs`) that was built and installed into the same store folder as otherwise this will cause build failures once a target actually depends on `lib:cpphs` This ought to fix haskell#5379
As the case of `cpphs-1.20.8` has shown in haskell#5379, in cases when a monolithic package gets installed due to its executable components (i.e. `exe:cpphs`) into the store we *have* to register if there's a buildable public library (i.e. `lib:cpphs`) that was built and installed into the same store folder as otherwise this will cause build failures once a target actually depends on `lib:cpphs` This ought to fix haskell#5379
…5604) As the case of `cpphs-1.20.8` has shown in #5379, in cases when a monolithic package gets installed due to its executable components (i.e. `exe:cpphs`) into the store we *have* to register if there's a buildable public library (i.e. `lib:cpphs`) that was built and installed into the same store folder as otherwise this will cause build failures once a target actually depends on `lib:cpphs` This ought to fix #5379
…5604) As the case of `cpphs-1.20.8` has shown in #5379, in cases when a monolithic package gets installed due to its executable components (i.e. `exe:cpphs`) into the store we *have* to register if there's a buildable public library (i.e. `lib:cpphs`) that was built and installed into the same store folder as otherwise this will cause build failures once a target actually depends on `lib:cpphs` This ought to fix #5379 (cherry picked from commit a4578fc)
|
@vmchale this should be fixed now and if it doesn't get reverted will be included in the next 2.4 point release; this should also be available for testing via my PPA in the next couple hours once the PPA builds of cabal-install have finished |
Occasionally, builds with
new-buildwill fail with the following:Builds with GHC 8.4.3 always work, but builds with past versions (such as 8.2.2, 8.0.2, etc.) will sometimes fail if cpphs has already been depended by a project using GHC 8.4.3.
This works on e.g. shake-literate with GHC 8.0.2, viz.
I'm using
cabal-headfrom the PPA.The text was updated successfully, but these errors were encountered: