Excerpts from Corey O'Connor's message of Sat Jan 15 11:44:22 +0100 2011: > Using parallel 2.2.0.1 is fine for GHC 6.12. However, when using GHC > 7, I prefer using vty with parallel 3.1.0.1. Course, depending on the > situation, somebody might want to use vty with parallel 3.1.0.1 under > GHC 6.12. Which leads me to wonder:
Let me tell you the ways I know about: A1) using ~/.nixpkgs/config.nix or (nixpkgs configuration section in nixos): http://www.mail-archive.com/[email protected]/msg08052.html A2) using override (this package only, create new name) vty2 = vty.override { parallel = parallel; }; A3) using system configuration: vty = callPackage ../development/libraries/haskell/vty { parallel = if (cgetConfig ["haskellPackages" "useparallel-2-2.."] ttrue) then parallel_2_2_0_1 else parallel; }; B) same as A3, but based on ghc version: vty = callPackage ../development/libraries/haskell/vty { # > must be encoded using builtins.lessThan parallel = if (builtins.versionCompare ghc.version "xxx" > "target-version") then parallel_2_2_0_1 else parallel; }; C) using deepOverride (sipirit of webkit) webkit = ((builderDefsPackage ../development/libraries/webkit { inherit (gnome28) gtkdoc libsoup; inherit (gtkLibs) gtk atk pango glib; inherit freetype fontconfig gettext gperf curl libjpeg libtiff libpng libxml2 libxslt sqlite icu cairo perl intltool automake libtool pkgconfig autoconf bison libproxy enchant python ruby which flex geoclue; inherit (gst_all) gstreamer gstPluginsBase gstFfmpeg gstPluginsGood; inherit (xlibs) libXt renderproto libXrender; }).deepOverride {libsoup = gnome28.libsoup_2_31;}); Eelco once said he dislikes this way - because it forces passing a different libsoup to to all packages. Maybe his disliking stopped when callPackages was introduced - because he never replied /commented on my patch which improved deep overriding !?) although I asked about 3 times! It was about this patch (I'm still rebasing it): http://thread.gmane.org/gmane.linux.distributions.nixos.scm/382/focus=5041 D) use hack-nix. You have a "haskell-package" configuration consisting of - a pool of packages (most are taken from hackage, but you can add your own) - a set of attributes patching the generated stuff (eg adding c depnedencies, setting flags, ..) Then a brute force solver tries to find a valid solution for the set of packages you're interested in. Here you can easily replace packages by others in the pool or change cabal configurations for each build taking place. I haven't tried building anything using ghc-7 yet. comments: ========== You only want to have a closer look at B,C,D because they let you override the package version for a different ghc version only D) is superior to A-C because it will tell you before starting to build that the versions you selected match (according to .cabal files) - or it will fail. I was told that have "dozens" of things in my mind at the same time - and that's not always easy to follow me. So bear with me and ask if there are any questions left. Currently I'm talking to Andres Loeh to make him understand more about hack-nix - so that we eventually can join efforts maintaining one way of building packages using Nix in the future. Marc Weber _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
