Building a specific target can cause bad state #2904
(Using stack-1.3.2 on Arch Linux)
Steps to reproduce
Clone this sample project with two libraries: LibA, and LibB which depends on LibA.
$ ls lib-a lib-b stack.yaml
Next, change a function (named
Now try to rebuild LibB with
stack should update (relink?) LibB to use the new version of LibA.
stack never rebuilds LibB, causing it to forever use the old LibA.
This was suprising for me, because I thought
After making a change in LibA and running
Alternatively, never build a specific target (e.g.
The text was updated successfully, but these errors were encountered:
It looks like
But the issue still exists:
This reminds me of haskell/cabal#2830. And in fact I'm seeing something very similar. When I do the initial
If I modified the
This is really a Cabal or GHC bug (it should generate unique package IDs if the package contents change). A simple workaround would be to aggressively unregister all users of a package when unregistering the dependency.
The previous commit (fixing #2904) made the Maybe layer confusing and error-prone. It was too easy to end up accidentally skipping an unregister based on the two levels of Maybe wrapping. This simplifies the codebase, without any change in behavior. It would be even nicer to be able to prove statically that we always generate a dirty reason.