We cannot pass the --{enable,disable}-executable-dynamic flags to GHC
versions prior to 7.4.x.
Building shared libraries via --{enable,disable}-shared is possible in theory
with GHC 6.12.x or later, but doesn't work in practice because our GHC 6.10.x
builds don't provide shared versions of their base libraries. This could
probably be fixed, but it's probably not worth the effort.
enableSharedLibraries configures Cabal to build of shared libraries. This
option requires that all dependencies of the package have been compiled
for use in shared libraries, too.
enableSharedExecutables configures Cabal to prefer shared libraries when
linking executables.
This patch partly fixes issue #1084.
The dns packages requires this feature, because it ships two test programs: one
of them requires network access (so we cannot run it), but the other test does
not. Setting testTarget appropriately allows us to run only one of the two
suites.
Haskell packages that contain non-ascii characters in their .cabal file
or somewhere else in their haddock documentation fail to compile under
nixpkgs and usually flagged with noHaddock = true. I wanted to do the
same for modularArithmentic, when I realized that we just have to set
the locale to some UTF-8 compatible locale in build-support/cabal to fix
this issue correctly.
Conflict in kerberos, which was updated both in master and in
stdenv-updates. Kept the stdenv-updates version, except pulled in the
enableParallelBuilding change from master.
Signed-off-by: Shea Levy <shea@shealevy.com>
Conflicts:
pkgs/development/libraries/kerberos/krb5.nix
The wrapper script accumulated some cruft over the last couple of months
because we did changes in freaky ways to avoid triggering re-builds of all
Haskell packages. Most of these kludges have been thrown out now.
This patch doesn't change the behavior of the wrapper except for one thing: the
internal helper scripts "ghc-get-packages.sh" and "ghc-packages.sh" are no
longer installed in the bin directory of the generated derivation.
The previous implementation used the following tying-the-knot trickery to
override 'doCheck' to false for the given build:
cabalNoTest = {
mkDerivation = x: rec {
final = self.cabal.mkDerivation (self: (x final) // { doCheck = false; });
}.final;
};
That seemed to work, but for some reason it caused trouble with some builds --
not all -- that use jailbreakCabal. The problem was the 'stdenv' attribute
couldn't be evaluated properly anymore:
$ nix-build ~/pkgs/top-level/release-haskell.nix -A optparseApplicative.ghc6104.x86_64-linux --show-trace
error: while evaluating the attribute `drvPath' at `/nix/store/qkj5cxknwspz8ak0ganm97zfr2bhksgn-nix-1.5.2pre3082_2398417/share/nix/corepkgs/derivation.nix:19:9':
while evaluating the builtin function `derivationStrict':
while instantiating the derivation named `haskell-optparse-applicative-ghc6.10.4-0.5.2.1' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:40:13':
while evaluating the derivation attribute `configurePhase' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:107:13':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/strings.nix:55:26':
while evaluating the attribute `outPath' at `/nix/store/qkj5cxknwspz8ak0ganm97zfr2bhksgn-nix-1.5.2pre3082_2398417/share/nix/corepkgs/derivation.nix:18:9':
while evaluating the builtin function `getAttr':
while evaluating the builtin function `derivationStrict':
while instantiating the derivation named `jailbreak-cabal-1.1' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:40:13':
while evaluating the derivation attribute `nativeBuildInputs' at `/home/simons/.nix-defexpr/pkgs/stdenv/generic/default.nix:76:17':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/lists.nix:135:21':
while evaluating the attribute `buildInputs' at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:22:17':
while evaluating the builtin function `filter':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:22:60':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/top-level/haskell-packages.nix:119:17':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/customisation.nix:61:22':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/lib/customisation.nix:56:24':
while evaluating the builtin function `isAttrs':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/development/libraries/haskell/Cabal/1.14.0.nix:1:1':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/top-level/haskell-packages.nix:113:20':
while evaluating the attribute `final' at `/home/simons/.nix-defexpr/pkgs/top-level/haskell-packages.nix:114:7':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/build-support/cabal/default.nix:9:5':
while evaluating the function at `/home/simons/.nix-defexpr/pkgs/stdenv/generic/default.nix:51:24':
while evaluating the attribute `meta.license' at `/home/simons/.nix-defexpr/pkgs/development/libraries/haskell/Cabal/1.14.0.nix:17:5':
infinite recursion encountered
I tried to figure out why this happens, but eventually gave up. The new
implementation passes an argument called 'enableCheckPhase' to the Cabal
builder, which determines whether the user-specified doCheck value has any
effect or not. Now, a normal override can be used to disable unit testing.
It's quite amazing that we've managed to pass incorrectly spelled command line
flags to Cabal for ages without ever noticing. :-)
The search path options --extra-{include,lib}-dirs are usually unnecessary,
because the build environment is set up such that gcc and ld find those headers
and libraries automatically, i.e. without needing extra flags. The bubble burst
on MacOS X, though, where the build of haskell-text-icu couldn't find the icu
library without manually setting DYLD_LIBRARY_PATH in that build. Fortunately,
cabal takes care of that issue if a correctly spelled --extra-lib-dirs flag is
passed.
Conflicts:
pkgs/development/libraries/libxslt/default.nix
Commit 1764ea2b0a introduced changes to libxslt
in an awkward way to avoid re-builds on Linux. This patch has been simplified
during this merge.
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.
According to <http://hackage.haskell.org/trac/ghc/ticket/4013>, this
feature won't work with XCode versions older than 3.2.
This means that Mac users will have considerably larger binaries because
some build-time dependencies (such as HTTP) will be mis-detected as
run-time dependencies.
This patch configures all Cabal builds with '--enable-split-objs' unless the
Nix expression explicitly sets "enableSplitObjs = false". The Cabal manual [1]
describes this option as follows:
| The GHC -split-objs reduces the final size of the executables that use the
| library by allowing them to link with only the bits that they use rather
| than the entire library. The downside is that building the library takes
| longer and uses considerably more memory.
One immediate benefit of this change is that the 'darcs' closure defined in the
top-level no longer refers to GHC. The same is probably true with other
executable packages.
[1] http://www.haskell.org/cabal/users-guide/installing-packages.html#setup-configure
Jailbreaks-cabal allows Nixpkgs maintainers to quick-fix builds of packages
that over-specify their version requirements by removing the version
restrictions of all dependencies from the Cabal file. Set
jailbreak = true
in the build expression to activate this feature.
