into haskell-packages.nix, which depends on an instance of GHC.
This allows a consistent set of packages to be built with the same
GHC. For instance,
$ nix-build -A haskellPackages_ghc683.xmonad
builds xmonad and all its dependencies with GHC 6.8.3, while
$ nix-build -A haskellPackages_ghc6102.xmonad
does the same with GHC 6.10.2. This is the same technique used with
kernelPackages. It also means that we don't need things like
"cabal682" and "cabal683" anymore.
* The setup hook is now in a separate wrapper package so that we don't
have to recompile all of GHC every time we want to make a small
change.
* cinelerra: this package appears to have an accidental dependency on
the "X11" Haskell package.
svn path=/nixpkgs/trunk/; revision=15125
the package).
* Removed the old ghc-wrapper, which hasn't been used for a long time.
* Renamed the "boot" GHC to "binary", which is more descriptive.
(They *can* be used for other things than bootstrapping a GHC
source build.)
* Updated the GHC 6.10.1 binary to 6.10.2.
svn path=/nixpkgs/trunk/; revision=15095
a Haskell library for timed command execution.
For starters, the expression lives in development/libraries/haskell/maybench.
It doesn't really belong there because, though, because, technically, it's an
executable, not a library. If someone has a better idea, please feel free to
move it.
svn path=/nixpkgs/trunk/; revision=12761
Setup: ../LICENSE: copyFile: does not exist (No such file or directory)
I'm not sure where this comes from. Also, it seems that passing haxr-th the
library haxr as a build input doesn't suffice; it also needs to be passed the
libraries that haxr depends on to configure successfully. Something isn't
right. Andreas, do you know how to fix this?
svn path=/nixpkgs/trunk/; revision=12722
* transformed zlib, vty, binary, X11 to use generic Cabal builder
* note that Cabal library packages are now by default prefixed with "haskell-"
svn path=/nixpkgs/trunk/; revision=10247
Just install ghc68_wrapper which will install the required dependencies ghc
(and libraries) itself.
The list libraries given in the wrapper attribute set can be user tuned in the future ?
An alternative would be creating something similar to the gcc/g++ include/ lib/ scheme which
is could be used by ghc to find installed packages..
svn path=/nixpkgs/trunk/; revision=9581
ghcPkgUtil defines a function to create setup-hook
- creating a packagedatabase (nix-support/package.conf)
- adding it to GHC_PACKAGE_PATH
see comments for details
svn path=/nixpkgs/trunk/; revision=9500
note: the old GHC 6.4(.2?) version is still there. I reused the bootstrap-version to bootstrap GHC-6.6. And some other packages depend on the old GHC
version as well.
note: only use this package for building other packages. If you install it as an end-user, you'll only be able to use the default GHC libraries,
because other libraries are only privately registered to this GHC version during a nix-build by hooks (which are not executed when you run GHC
yourself as an end-user).
Consequently, also added a newer version of uulib and uuagc.
svn path=/nixpkgs/trunk/; revision=7346
