This predicate filters out packages that weren't created by the Cabal builder.
Doing that greatly reduces the likelihood of file collisions in the generated
environment, because Haskell packages tend to have a lot of propagated build
inputs.
For example, both zeromq 2.x and 3.x use the same names for their header files.
Users of haskell-zeromq don't need those headers, so we just don't include them
in the generated environment to avoid the collision that would otherwise occur
when haskell-zeromq 2.x and 3.x are installed into the same environment.
uses for its core libraries, so that these files integrate seamlessly into one
profile, living right next to each other. This change is eventually going to
simply our with-packages wrapper quite a bit.
When the ghc-paths library is compiled, the paths of the
compiler it is compiled with are being hardcoded in the
library (and can then be queried from other applications
using the library).
But on Nix, packages are compiled with ghc-wrapper, and
subsequently possibly used with a special version of ghc
generated for a particular environment of packages. So
one version of ghc-paths may potentially end up being
used by lots of different instances of ghc. The hardcoding
approach fails.
As a work-around, we now patch ghc-paths so that it allows
setting the paths that can be queried via environment
variables. Specific GHC environments can then set these
environment variables in the wrapper shell script that
invokes GHC.
This should at least partially solve issue #213.
This change allows use of the with-packages wrapper in user profiles that are
being updated with "nix-env -u \*". The previous name this expression generated
was considered by Nix to be an older version of "ghc-7.0.4-wrapper", because
that name has a higher priority.
svn path=/nixpkgs/trunk/; revision=33325
