On 7/15/07, Isaac Dupree <[EMAIL PROTECTED]> 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 _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel
