Re[2]: [Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

2008-10-14 Thread Bulat Ziganshin
Hello Thomas,

Tuesday, October 14, 2008, 2:46:45 PM, you wrote:

> The issue is binary compatibility.  At the moment, GHC cannot make
> sure that a library compiled with an older GHC can work with a newer
> GHC.  GHC does many cross-module optimisations, and its runtime system
> changes occasionally, so it is very pessimistic in that regard.  This
> becomes an issue for packages that GHC has been build with itself
> (like base, process, array), since these cannot be upgraded without
> recompiling GHC (hence requiring recompiling every other package).

is this correct? i was under impression that upgrading packages never
require to recompile GHC itself. it just happen that we have only one
version of base or array shipped with each GHC and at least with array
this can be changed easily (and for base too - just noone plans to do
it)


-- 
Best regards,
 Bulatmailto:[EMAIL PROTECTED]

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Re[2]: [Haskell-cafe] I do not want to be a bitch, but ghc-6.8.3 and haskell binary policy are really horrible.

2008-10-14 Thread Thomas Schilling
2008/10/14 Bulat Ziganshin <[EMAIL PROTECTED]>:
> Hello Thomas,
>
> Tuesday, October 14, 2008, 2:46:45 PM, you wrote:
>
>> The issue is binary compatibility.  At the moment, GHC cannot make
>> sure that a library compiled with an older GHC can work with a newer
>> GHC.  GHC does many cross-module optimisations, and its runtime system
>> changes occasionally, so it is very pessimistic in that regard.  This
>> becomes an issue for packages that GHC has been build with itself
>> (like base, process, array), since these cannot be upgraded without
>> recompiling GHC (hence requiring recompiling every other package).
>
> is this correct? i was under impression that upgrading packages never
> require to recompile GHC itself. it just happen that we have only one
> version of base or array shipped with each GHC and at least with array
> this can be changed easily (and for base too - just noone plans to do
> it)

Well, I was a bit imprecise.  You can install a new array, but if you
have a transitive dependency on the old array, this won't help.  I'm
not sure, but AFAIK the only thing that can introduce such a
transitive dependency is the GHC API.  So if you want to use the GHC
API and a newer version of array in your program then you need to
recompile ghc against the new array package.

If you don't use the GHC API but want to use another package that has
been compiled against array, you need to upgrade that other package,
too.  Modern versions of cabal-install should be able to do this where
possible, but older ones (< 0.5, I think, Duncan knows) had problems
with this.

P.S.: I guess the moral of the story is that while cabal upgrade (no
args) seems like a reasonable thing to do it is not yet very
realiable.  Many of these issues only became urgent because we now
have such a powerful tool like cabal-install and we now have to add
features to GHC, Cabal, and cabal-install to solve them.  So, despite
these unfortunate (and understandably frustrating) issues, we've come
a long way since only 2 years ago, where every package had to be
downloaded and installed manually using runghc Setup.

P.P.S: Again, to the OP, please help us find out what exactly went
wrong, so we can try to make sure that it won't happen again to you or
anyone else.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users