[gobolinux-devel] [gobolinux-users] Haskell Cabal build type?

[hisham.hm at gmail.com]

On 7/15/07, Isaac Dupree <isaacdupree at charter.net> wrote:
>
> New versions of Happy and Alex require Cabal (The Haskell Cabal: Common
> Architecture for Building Applications and Libraries,
> <http://haskell.org/cabal/>) instead of 'configure'-type build. (and I
> need those new versions in order to develop GHC HEAD)  More applications
> written in Haskell are likely to use this in the future.  That's not so
> bad if we can just make a new recipe type.

Yes, it would be good to have.

> Common Haskell libraries are being split up into separate pieces and
> less offered installed with newer releases of the GHC compiler.  We
> don't want to flood the /Programs namespace with all different little
> Haskell libraries; and each Cabal-based program-or-library declares
> which packages/modules/libraries it depends on, in a standard .cabal
> file.  We shouldn't try to manually keep intra-Haskell dependency
> listings in sync with these, either, as they are likely to change
> frequently.  Given how GHC normally works, it puts these in a system
> shared directory named by the GHC version (since e.g. GHC 6.6 and GHC
> 6.6.1 -generated binaries are incompatible with each other).  So if an
> installed /Programs/GHC/6.6.1/ is used, should the libraries be
> installed somewhere inside /Programs/GHC/6.6.1/ perhaps?  I'm thinking
> Perl modules may be a similar existing issue; are they handled well, and
> if so, how? (I'm afraid it may be that they are handled poorly, from
> what I am hearing recently with Pidgin Unmanaged files, HAL failing to
> Compile... but I don't know.  Any information is better than none.)

There have been problems in the past with the configuration of Perl,
but I think things are now mostly settled on how to put Perl modules
in the GoboLinux tree. Cabal has been mentioned here before, but a
practical problem was that it maintains a database file that needs to
be edited globally (ie, outside its own /Programs entry).

But having their own package management schemes this is a route that
all scripting languages are going for with their modules: Perl with
CPAN, Ruby with RubyGems, Python with Python Eggs, Lua with LuaRocks.
I'm CCing gobolinux-devel on this, as I think it's a worthwhile
discussion to see on which way we're going. It may be better to just
leave all those modules managed by their languages' managers, off the
main /Programs tree. I understand some people already do this for
RubyGems.

-- Hisham