All JARs in $pkg/share/java (for each $pkg in the build inputs) are
added to $CLASSPATH. Thus, you can say
buildInputs = [ setJavaClassPath someJavaDependency ];
and the JARs in someJavaDependency will be found automatically by
tools like javac or ant.
Note that the manual used to say that JARs should be installed in
lib/java; this is now share/java, following the Debian policy:
http://www.debian.org/doc/packaging-manuals/java-policy/x110.html
The directory share/java makes more sense because JARs are
architecture-independent. (Also, a quick grep shows that we were not
exactly consistent about this in Nixpkgs.)
disabled by setting 'strictConfigurePhase' to 'false'
This is necessary for some packages, like dns, because cabal warns about
multiple versions of the same dependency being used, but the usage is fine,
actually, so we want the build to succeed. Packages that depend on 'doctest'
also have this issue <https://github.com/sol/doctest-haskell/issues/69>.
Before this commit, if a haskell library X depends on Y, and X was added to
systemPackages, only X would be available in the user environment. Y
would not be avialable, which causes X to be broken. This commit solves
the issue by setting propagatedUserEnvPkgs to all packages X depends
on when X is a library.
The nix-prefect git script was broken when trying to parse certain
groups of submodules. This patch fixes the url detection for submodule
repositories to use the more reliable `git config` commands.
* There now is full support for building Haskell packages as shared libraries
for GHC versions 7.4.2 or later. The Cabal builder recognizes the following
attributes:
- enableSharedLibraries configures Cabal to build of shared libraries in
addition to static ones. 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.
The default values for these attributes are arguments to the haskellPackages
expression.
* Haskell builds now run in a LANG="en_US.UTF-8" environment to avoid plenty
of build and test suite errors. Without this setting, GHC seems unable to
deal with the UTF-8 character encoding that's generally considered standard
in the Haskell world.
* The Cabal builder supports a new attribute 'testTarget' to specify the exact
set of tests to be run during the check phase.
* The ghc-wrapper attribute ghcVersion has been removed. Instead, we use the
ghc.version attribute, which exists in unwrapped GHC derivations, too.
The default target (i386-linux) causes flags like "-march i386" to be
added, which breaks on recent Fedora releases (18 and up), resulting
in errors like:
/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48: undefined reference to `__atomic_fetch_add_4'
So set the target to i686-linux.
http://hydra.nixos.org/build/6567357
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.
Kept the old hacks where they don't break the build in case they things
they fix are still relevant.
I checked that the upgrade doesn't break:
1) Asymptote and EProver builds.
2) My XeLaTeX demo from configurations/ repository.
3) Some of my own files.
The upgrade fixes problems with simultaneous use of 3D and LaTeX labels
in Asymptote.
Please provide a test that worked previously and is broken now if you
need to revert this update or its parts.
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.
Wheezy has been released on June 15th and on all mirrors the SHA256 hash
of Packages.bz2 has changed to reflect the new release, so let's update.
Here is the release announcement from Debian:
http://www.debian.org/News/2013/20130615
It also seems that the versioning scheme has changed in version 7.x, so
they seem to have switched to a two digit versioning scheme. This means,
that the attribute name "debian70..." should really be something like
"debian7...", but I'm keeping the attribute as-is to not break
references.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is needed in order to prevent services from starting while
populating the image with the contents of the .deb files. The procedure
used here is exactly the same as used in debootstrap.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
9p (with caching enabled) is much faster than CIFS and doesn't require
Samba or virtual networking. For instance, building GNU Hello with
CIFS takes ~323s on my laptop, but with 9p it takes 54s.
More measurements will be needed to see if "cache=fscache" is really
faster than "cache=loose" (the former seems to be a little bit
faster).
This only ever worked because runInLinuxVM happened to call
overrideDerivation, which itself erroneously passed arbitrarily-added
attributes to the new call to derivation.
Hopefully this time Eelco won't have to revert my change ;)
Signed-off-by: Shea Levy <shea@shealevy.com>
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.
![](https://secure.gravatar.com/avatar/2f93d08a773b27d6548598c5f45aa3a9?d=identicon&s=56 "Jason \\"Don\\" O'Conal"){kind=small}
