dev/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

* Updated the Perl section of the manual.

Browse Source 
svn path=/nixpkgs/trunk/; revision=15173
This commit is contained in:
Eelco Dolstra 2009-04-20 12:23:01 +00:00
parent b7c0e6b66b
commit dd2e74e02b
1 changed files with 25 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
doc/language-support.xml
View File

@ -20,9 +20,15 @@ a generic package builder function for any Perl package that has a
standard <varname>Makefile.PL</varname>. It’s implemented in <link standard <varname>Makefile.PL</varname>. It’s implemented in <link
xlink:href="https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/development/perl-modules/generic"><filename>pkgs/development/perl-modules/generic</filename></link>.</para> xlink:href="https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/development/perl-modules/generic"><filename>pkgs/development/perl-modules/generic</filename></link>.</para>
<para>Most Perl packages from CPAN are so straight-forward to build <para>Perl packages from CPAN are defined in <link
that they are defined in <filename>pkgs/all-packages.nix</filename> xlink:href="https://svn.nixos.org/repos/nix/nixpkgs/trunk/pkgs/top-level/perl-packages.nix"><filename>pkgs/perl-packages.nix</filename></link>,
itself. Here is an example: rather than <filename>pkgs/all-packages.nix</filename>. 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 <filename>perl-packages.nix</filename>. However, more
complicated packages should be put in a separate file, typically in
<filename>pkgs/development/perl-modules</filename>. Here is an
example of the former:
<programlisting> <programlisting>
perlClassC3 = buildPerlPackage rec { perlClassC3 = buildPerlPackage rec {
@ -37,10 +43,23 @@ perlClassC3 = buildPerlPackage rec {
Note the use of <literal>mirror://cpan/</literal>, and the Note the use of <literal>mirror://cpan/</literal>, and the
<literal>${name}</literal> in the URL definition to ensure that the <literal>${name}</literal> in the URL definition to ensure that the
name attribute is consistent with the source that we’re actually name attribute is consistent with the source that we’re actually
downloading. As usual, you can test this package as follows: downloading. Perl packages are made available in
<filename>all-packages.nix</filename> through the variable
<varname>perlPackages</varname>. For instance, if you have a package
that needs <varname>perlClassC3</varname>, you would typically write
<programlisting>
foo = import ../path/to/foo.nix {
inherit stdenv fetchurl ...;
inherit (perlPackages) perlClassC3;
};
</programlisting>
in <filename>all-packages.nix</filename>. You can test building a
Perl package as follows:
<screen> <screen>
$ nix-build -A perlClassC3 $ nix-build -A perlPackages.perlClassC3
</screen> </screen>
<varname>buildPerlPackage</varname> adds <literal>perl-</literal> to <varname>buildPerlPackage</varname> adds <literal>perl-</literal> to
@ -53,7 +72,7 @@ $ nix-env -i perl-Class-C3
</screen> </screen>
(Of course you can also install using the attribute name: (Of course you can also install using the attribute name:
<literal>nix-env -i -A perlClassC3</literal>.)</para> <literal>nix-env -i -A perlPackages.perlClassC3</literal>.)</para>
<para>So what does <varname>buildPerlPackage</varname> do? It does <para>So what does <varname>buildPerlPackage</varname> do? It does
the following: the following: