The standard build environment makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accomodated by overriding the appropriate phases of stdenv. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.

Nixpkgs provides a function buildPerlPackage, a generic package builder function for any Perl package that has a standard Makefile.PL. It’s implemented in pkgs/development/perl-modules/generic. Perl packages from CPAN are defined in pkgs/top-level/perl-packages.nix, rather than pkgs/all-packages.nix. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from perl-packages.nix. However, more complicated packages should be put in a separate file, typically in pkgs/development/perl-modules. Here is an example of the former: ClassC3 = buildPerlPackage rec { name = "Class-C3-0.21"; src = fetchurl { url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz"; sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz"; }; }; Note the use of mirror://cpan/, and the ${name} in the URL definition to ensure that the name attribute is consistent with the source that we’re actually downloading. Perl packages are made available in all-packages.nix through the variable perlPackages. For instance, if you have a package that needs ClassC3, you would typically write foo = import ../path/to/foo.nix { inherit stdenv fetchurl ...; inherit (perlPackages) ClassC3; }; in all-packages.nix. You can test building a Perl package as follows: $ nix-build -A perlPackages.ClassC3 buildPerlPackage adds perl- to the start of the name attribute, so the package above is actually called perl-Class-C3-0.21. So to install it, you can say: $ nix-env -i perl-Class-C3 (Of course you can also install using the attribute name: nix-env -i -A perlPackages.ClassC3.) So what does buildPerlPackage do? It does the following: In the configure phase, it calls perl Makefile.PL to generate a Makefile. You can set the variable makeMakerFlags to pass flags to Makefile.PL It adds the contents of the PERL5LIB environment variable to #! .../bin/perl line of Perl scripts as -Idir flags. This ensures that a script can find its dependencies. In the fixup phase, it writes the propagated build inputs (propagatedBuildInputs) to the file $out/nix-support/propagated-user-env-packages. nix-env recursively installs all packages listed in this file when you install a package that has it. This ensures that a Perl package can find its dependencies. buildPerlPackage is built on top of stdenv, so everything can be customised in the usual way. For instance, the BerkeleyDB module has a preConfigure hook to generate a configuration file used by Makefile.PL: {buildPerlPackage, fetchurl, db}: buildPerlPackage rec { name = "BerkeleyDB-0.36"; src = fetchurl { url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz"; sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1"; }; preConfigure = '' echo "LIB = ${db}/lib" > config.in echo "INCLUDE = ${db}/include" >> config.in ''; } Dependencies on other Perl packages can be specified in the buildInputs and propagatedBuildInputs attributes. If something is exclusively a build-time dependency, use buildInputs; if it’s (also) a runtime dependency, use propagatedBuildInputs. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules: ClassC3Componentised = buildPerlPackage rec { name = "Class-C3-Componentised-1.0004"; src = fetchurl { url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz"; sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1"; }; propagatedBuildInputs = [ ClassC3 ClassInspector TestException MROCompat ]; };

Nix expressions for Perl packages can be generated (almost) automatically from CPAN. This is done by the program nix-generate-from-cpan, which can be installed as follows: $ nix-env -i nix-generate-from-cpan This program takes a Perl module name, looks it up on CPAN, fetches and unpacks the corresponding package, and prints a Nix expression on standard output. For example: $ nix-generate-from-cpan XML::Simple XMLSimple = buildPerlPackage { name = "XML-Simple-2.20"; src = fetchurl { url = mirror://cpan/authors/id/G/GR/GRANTM/XML-Simple-2.20.tar.gz; sha256 = "5cff13d0802792da1eb45895ce1be461903d98ec97c9c953bc8406af7294434a"; }; propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ]; meta = { description = "Easily read/write XML (esp config files)"; license = "perl"; }; }; The output can be pasted into pkgs/top-level/perl-packages.nix or wherever else you need it.

Python packages that use setuptools, which many Python packages do nowadays, can be built very simply using the buildPythonPackage function. This function is implemented in pkgs/development/python-modules/generic/default.nix and works similarly to buildPerlPackage. (See for details.) Python packages that use buildPythonPackage are defined in pkgs/top-level/python-packages.nix. Most of them are simple. For example: twisted = buildPythonPackage { name = "twisted-8.1.0"; src = fetchurl { url = http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/Twisted-8.1.0.tar.bz2; sha256 = "0q25zbr4xzknaghha72mq57kh53qw1bf8csgp63pm9sfi72qhirl"; }; propagatedBuildInputs = [ pkgs.ZopeInterface ]; meta = { homepage = http://twistedmatrix.com/; description = "Twisted, an event-driven networking engine written in Python"; license = "MIT"; }; };

For example, to package yajl-ruby package, use gem-nix: $ nix-env -i gem-nix $ gem-nix --no-user-install --nix-file=pkgs/development/interpreters/ruby/generated.nix yajl-ruby $ nix-build -A rubyLibs.yajl-ruby

To extract dependency information from a Go package in automated way use go2nix.

Ant-based Java packages are typically built from source as follows: stdenv.mkDerivation { name = "..."; src = fetchurl { ... }; buildInputs = [ jdk ant ]; buildPhase = "ant"; } Note that jdk is an alias for the OpenJDK. JAR files that are intended to be used by other packages should be installed in $out/share/java. The OpenJDK has a stdenv setup hook that adds any JARs in the share/java directories of the build inputs to the CLASSPATH environment variable. For instance, if the package libfoo installs a JAR named foo.jar in its share/java directory, and another package declares the attribute buildInputs = [ jdk libfoo ]; then CLASSPATH will be set to /nix/store/...-libfoo/share/java/foo.jar. Private JARs should be installed in a location like $out/share/package-name. If your Java package provides a program, you need to generate a wrapper script to run it using the OpenJRE. You can use makeWrapper for this: buildInputs = [ makeWrapper ]; installPhase = '' mkdir -p $out/bin makeWrapper ${jre}/bin/java $out/bin/foo \ --add-flags "-cp $out/share/java/foo.jar org.foo.Main" ''; Note the use of jre, which is the part of the OpenJDK package that contains the Java Runtime Environment. By using ${jre}/bin/java instead of ${jdk}/bin/java, you prevent your package from depending on the JDK at runtime. It is possible to use a different Java compiler than javac from the OpenJDK. For instance, to use the Eclipse Java Compiler: buildInputs = [ jre ant ecj ]; (Note that here you don’t need the full JDK as an input, but just the JRE.) The ECJ has a stdenv setup hook that sets some environment variables to cause Ant to use ECJ, but this doesn’t work with all Ant files. Similarly, you can use the GNU Java Compiler: buildInputs = [ gcj ant ]; Here, Ant will automatically use gij (the GNU Java Runtime) instead of the OpenJRE.