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.... 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.

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.

Glad to hear that. I will checkout the trunk and try. On Fri, Feb 3, 2012 at 6:20 PM, Andres Löh wrote:

Hi.

On Fri, Feb 3, 2012 at 7:44 AM, 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.

It's a valid complaint, and there's ongoing work to fix some of these issues. In the meantime, the development version of cabal-install, in particular the new modular solver, can deal with a few situations that can't be resolved by older cabal-install versions. I can't promise it will help here. But I'm still interested in feedback.

Cheers,  Andres

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