Diego Souza wrote:

Hi,

currently when one install a cabal package it compiles it and then install generated binaries. I wonder whether or not it would be useful to have pre-compiled binaries as many package managers usually do (e.g. apt). I often think that would save some time on the expense of a busier hackage server capable of generating packages for many different platforms.

I'm particularly thinking on the following scenario: suppose that you have code that is ready for production. If cabal supported pre-compiled binaries, there is no need to install ghc or eventually any other compiler, just runtime environment and eventually cabal. I must say that I have no experience in doing this in Haskell (just personal/small projects), so I suppose one have to generate binaries and use other sort of package manager to deploy code to production (which sounds reasonable as well). Thus, if the assumption is correct, cabal is a development tool, not something one could to only deploy runtime-only packages.

I also would appreciate if others could share how usually this is managed.

As far as I know, Cabal is mainly used for deploying Haskell libraries. If you want to deploy a finished Haskell program, just compile it into an executable program and make it downloadable from somewhere. (Much like a C program or any other kind of program.) For example, if you hunt around, you can find Darcs available as a binary download (even for Windows). It might be nice if certain Haskell libraries were available in binary form. The trouble is, Haskell libraries have to be recompiled for each version of the compiler. This is why it's usually released in source form; otherwise you have to make a bazillion different binaries, one for every version of GHC on every platform that GHC runs on. Much easier to just compile from source, Unix-style. (And I've only come across one Haskell package that takes more than 11 seconds to compile anyway.)

On 28 February 2010 01:55, Diego Souza wrote:

currently when one install a cabal package it compiles it and then install generated binaries. I wonder whether or not it would be useful to have pre-compiled binaries as many package managers usually do (e.g. apt). I often think that would save some time on the expense of a busier hackage server capable of generating packages for many different platforms. I'm particularly thinking on the following scenario: suppose that you have code that is ready for production. If cabal supported pre-compiled binaries, there is no need to install ghc or eventually any other compiler, just runtime environment and eventually cabal. I must say that I have no experience in doing this in Haskell (just personal/small projects), so I suppose one have to generate binaries and use other sort of package manager to deploy code to production (which sounds reasonable as well). Thus, if the assumption is correct, cabal is a development tool, not something one could to only deploy runtime-only packages.

So, you need a binary for each version of GHC available (IIRC, Duncan is still testing new releases of Cabal for versions of GHC as old as 6.4) with and without profiling, with different possible optimization flags and for different architectures and operating systems... To me, that sounds like too much work. /me really wishes people stopped thinking of Cabal as a package manager -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Sat, 27 Feb 2010, Diego Souza wrote:

Hi, currently when one install a cabal package it compiles it and then install generated binaries. I wonder whether or not it would be useful to have pre-compiled binaries as many package managers usually do (e.g. apt). I often think that would save some time on the expense of a busier hackage server capable of generating packages for many different platforms.

There is cabal-rpm http://hackage.haskell.org/package/cabal-rpm