Re: [Haskell-cafe] Again, version conflicting problem with cabal-install

Yes and probably a runtime crash even if passed the compile. But I think if we let it stay the way it is, the hackage empire would be down any minute. All big hackages are depending on many other hackages by many other authors. So big chance that the top hackage cannot be installed (like I suffered recently). Maybe I should crack my cabal source to add an argument to ignore version checking.... On Fri, Feb 3, 2012 at 2:44 PM, Ivan Lazar Miljenovic wrote:

On 3 February 2012 17:29, Magicloud Magiclouds wrote:

...

Thank you. The document does say it more clearly than me. But still, currently, ghc only gives me one option: cannot be built. How about giving me another one: throw away the version information of D when building A. So when A uses types in D with B and C, it might work. Just the risk is on me now. It is not perfect, but would work sometimes....

But not always.  We'd then have other errors: "why isn't this build working?"

Types can be re-exported, class instances are implicitly imported/exported, etc.

...

On Fri, Feb 3, 2012 at 2:04 PM, Ivan Lazar Miljenovic wrote:

...

On 3 February 2012 16:54, Magicloud Magiclouds 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?  By version conflicting I mean like following. This way, A is not installable by cabal. A needs B 0.1 A needs C 0.1 B needs C0.2

See the Dreaded Diamond Dependency Problem: http://www.well-typed.com/blog/9

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

-- 竹密岂妨流水过 山高哪阻野云飞

And for G+, please use magiclouds#gmail.com.

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

-- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.