<div dir="ltr"><div class="gmail_extra">As I think Simon was saying earlier, think of this feature as allowing strictly more installation plans to succeed, while still keeping to the exact same model that we use today of just one instance of a lib in any given binary.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Currently, if you install B-0.1 and then install A-2.0 that has a constraint B>=0.1, then you can't build an app that depends on both A and B-0.2. That's counter intuitive because had you started from an empty sandbox, then you would be able to build the app!</div><div class="gmail_extra"><br></div><div class="gmail_extra">The reason is that currently you can only have a single instance of A-2.0 installed. The proposal is *not* to allow building an app against an A-2.0 built against B-0.1 and against B-0.2 simultaneously. It's to allow multiple instances of A-2.0 in the same package database, and teach Cabal to handle that, so that an app can ask for an A-2.0 that is built against the right version of B, no matter what, and link that in.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In your example, an app wouldn't get both C 1.0 and 2.0. It would get whichever one of those fits the constraints of both A and B, or the build will fail if no such C exists.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Since only one instance of a library ever makes it into a binary, as is the case currently, no particular problem arises with linking in external dependencies such as C code.</div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On 11 May 2015 at 14:52, Daniel Trstenjak <span dir="ltr"><<a href="mailto:daniel.trstenjak@gmail.com" target="_blank">daniel.trstenjak@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Simon,<br>
<span class=""><br>
On Mon, May 11, 2015 at 11:27:58AM +0000, Simon Peyton Jones wrote:<br>
> Well, no one is actually suggesting that!<br>
<br>
</span>But you're just getting it automatically if you're depending e.g.<br>
on the libraries A and B, and A depends on C 1.0 and B depends on C 2.0.<br>
<br>
Currently you can't build this dependency graph, right? And with<br>
this proposed feature you will be getting C 1.0 and 2.0 into your binary.<br>
<br>
<br>
Perhaps a even more nasty case is, if you're using a haskell library<br>
which wraps a stateful c library, and now you're having multiple<br>
versions of the same haskell library operating on the same c library state.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Greetings,<br>
Daniel<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</div></div></blockquote></div><br></div></div>