changes in dep packages are not included - solution in #2904 #3047 seems not to work always

[andrewufrank]

I have a package A which is build with stack producing a library. The library is used in package B (i.e. A is a dependent package listed in B's cabal file). B is build with stack as well. (git@github.com:andrewufrank/test-depProj.git)

When A changes then B continues to use the old state of A but should update. B is updated when A is not separately build with stack, but not if build stack is executed in A.

This seems to be the previously reported problem (caused by cabal using the same id) and is supposed to be fixed in 1.4.0, but it appears that this is not always the case.
For clarification the stack.yam of A

flags: {}
extra-package-dbs: []
packages:
- .
extra-deps: []
resolver: lts-8.13

and for B

flags: {}
extra-package-dbs: []
packages:
- .
- ../a
extra-deps: []
resolver: lts-8.13

The procedure I followed was:

• clone repository.
• open two terminals for a and b, stack build in each; everything ok.
• edit LibA.hs, add a function secondFunc wtih no argument. stack build in terminal a.
• edit Main.hs in b/app to call function secondFunc . save and stack build in b.
• Error is variable not in scope (and a was not accessed).

I use

stack --version
Version 1.4.0, Git revision e714f1dd3fade19496d91bd6a017e435a96a6bcd (4640 commits) x86_64 hpack-0.17.0

with cabal-install version 1.24.0.2 on debian stretch amd64 (but same behavior observed on debian jessie ARM).

[andrewufrank]

i have build a version of stack from github and tested.
Version 1.4.1, Git revision 0ddbaa7fd1cfe8ec4c8cb17364dc8f0aa6d4314d (4766 commits) x86_64 hpack-0.17.0
The behaviour is the same as reported above and the same as reported in #3130.

reading the history of #2904 and the conversation with the cabal developers in #4381 is revealing the cause as a change in cabals use of ID, which cannot serve the requirements of stack when deciding if a rebuild is necessary or not (the cabal produced ID does not reflect the state of the code, not even the state of the interface (unless i misread #4381 completely)).
I suggest that stack constructs its own ID from a package (timestamp and/or md5 or similar from source file) so stack can certainly identify when the file has changed.

[mpilgrem]

I am closing this issue given the passage of time and because I cannot reproduce the example given with Stack 2.15.3: stack build foo-b rebuilds foo-a.