How to make GHC 6.6 and 6.8 co-exist -- was: First go at reactive programming
I want to raise this issue again since I disagreed (see quoted text
below) that cabal-install can solve the problem of moving from one
version to another completely.
For most /pure/ packages, it is probably true. But for those packages
that have external depedencies, this is hardly so. For example,
HDBC-OBDC package depends on where the odbc driver is installled. You
actually have to modify the
...
I am asking this question in another thread. The problem is -- I've got many modules compiled under 6.6, some with much agony. If I switch to 6.8, I have to recompile them again. Two issues I image:
(1) It may take lots of effort to recompile all the modules. I have forgetten how I got around some of the modules! Too bad... Got to take notes next time...
These days, every package you'd want to install (with the exception of GHC, Darcs, and the large graphics toolkits) should be available on Hackage or at least in Cabalized form.
If they aren't, then that's a bug or at least missing feature. The whole point of Cabal was so you don't have to take notes!
stevelihn wrote:
In my brief experience with Ocaml's GODI, GODI has a way to specify them in a so-called config package. The install package then reads what it needs from the config package. In perl's CPAN shell, you can specify them in the cpan config file (to some extent).
I suggest cabal-install looks into this so that moving from one version to another is indeed painless. 6.8.(1|2) is never the last Haskell version. The fact that Cabal records the 3rd digit version in the path indicates a diligent user has to re-install all the packages on every new 3rd-digit dot release. That is a lot of work!
I like this idea (and I suggested it previously :-) http://www.mail-archive.com/haskell-cafe@haskell.org/msg33790.html It would also potentially solve problems with win32 versus unix installations also. Of course, suggesting is the easy bit... Tim
On Tue, 2008-01-29 at 06:15 +0000, Tim Docker wrote:
stevelihn wrote:
In my brief experience with Ocaml's GODI, GODI has a way to specify them in a so-called config package. The install package then reads what it needs from the config package. In perl's CPAN shell, you can specify them in the cpan config file (to some extent).
I suggest cabal-install looks into this so that moving from one version to another is indeed painless. 6.8.(1|2) is never the last Haskell version. The fact that Cabal records the 3rd digit version in the path indicates a diligent user has to re-install all the packages on every new 3rd-digit dot release. That is a lot of work!
I like this idea (and I suggested it previously :-)
http://www.mail-archive.com/haskell-cafe@haskell.org/msg33790.html
It would also potentially solve problems with win32 versus unix installations also. Of course, suggesting is the easy bit...
Could one of you please file a feature request: http://hackage.haskell.org/trac/hackage It's also related to these tickets which you may like to comment on: * http://hackage.haskell.org/trac/hackage/ticket/199 "when installing a new version of GHC, there should be a way to upgrade my packages" * http://hackage.haskell.org/trac/hackage/ticket/216 "need a way to specify the foreign libraries a package depends on" My thoughts on the issue are that we should aim to make installation as automatic as possible. We don't want users having to enter extra information when it is not essential. There are times when we cannot possibly detect where some C lib is installed however and then we should be able to pass extra linker and include dirs to cabal. I'd do these as configure flags, since that will work well for systems like Nix and nearly automatically allow such things to be specified in cabal-install's configure file, though it'd need some extra work to allow such things to be specified per-package. Duncan
participants (3)
-
Duncan Coutts -
Steve Lihn -
Tim Docker