In my experience the diamond of death is typically because: * You install package A that uses C-0.1 * Someone uploads C-0.2 to hackage * Later you 'cabal update', this does not rebuild A to use C-0.2, even though it could. * You install package B that uses C, and cabal builds it with C-0.2 * Now you want to build D that uses A and B, but A requires C-0.1 and B requires C-0.2, even though they could be rebuilt to use the same C.
Typically, the constraints on A, B, and D would all accept the same version of C. Except that when they were compiled separately and C changed between building A and B, then the compiled versions become fixed on C-0.1 and C-0.2. It's true that it won't solve it in all cases, but in my experience using cabal-dev made the problem go away. I hope that clarifies. Jason On Fri, Feb 3, 2012 at 7:33 AM, Magicloud Magiclouds <magicloud.magiclo...@gmail.com> wrote: > Well, cabal-dev could not resolve the conflict of "the diamond". > Because the conflict is "depending different version at the SAME > time". > > On Fri, Feb 3, 2012 at 9:20 PM, Jason Dagit <dag...@gmail.com> wrote: >> On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds >> <magicloud.magiclo...@gmail.com> wrote: >>> Hello, >>> As I recalled, ghc works in staticly link mode. So after one library >>> is compiled, all its build dependencies are useless. Lost, changed, >>> wheresoever, it does not matter. >>> Then why the problem of version conflicting exists? >> >> I'm not sure, but for me this problem has gone away by using cabal-dev >> to build everything. >> >> Jason > > > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe