Dear Café, The reasonable explanation for this issue is that changing where splitmix comes from changes the version of random. When using only dependencies from Hackage, I got random-1.2 (latest version). When depending on splitmix locally (same version), I got random-1.1. cabal refuses to upgrade to 1.2, presumably because it sees a spurious cyclic dependency: random-1.2 depends on splitmix whose test suite depends on random. So there is a discrepancy in how cabal handles local packages, but at least it's not as weird as my previous hypothesis of building with different compiler flags. Li-yao On 8/6/2020 9:52 PM, Li-yao Xia wrote:
Hello Café,
I've been testing properties of some optimized Core using the inspection-testing library. Some functions appear to be optimized differently depending on whether one of the package dependencies comes from Hackage or elsewhere. As far as I can tell, the source code is identical, and the only difference is whether or not I add the path to the local package in my cabal.project.
Why would a dependency be compiled differently depending on where it comes from? Any suggestions on how to troubleshoot this?
To be more concrete, the relevant packages are generic-random and splitmix. The following commands should reproduce the issue:
git clone https://github.com/Lysxia/generic-random git clone https://github.com/phadej/splitmix cd generic-random
# With local splitmix echo "packages: . ../splitmix" > cabal.project cabal test --flags="enable-inspect" # PASS
# With remote splitmix echo "packages: ." > cabal.project cabal test --flags="enable-inspect" # FAIL
It would be useful to know whether anyone can reproduce this behavior or not.
Cheers, Li-yao
PS, link to Github issue: https://github.com/Lysxia/generic-random/issues/22