···

       
50
       
 
       
    In addition to <literal>plugins</literal> the options

     

       
51
       
 
       
    <literal>extraDeps</literal> and <literal>perlDeps</literal> can be used

     

       
52
       
 
       
    to install extra packages.

     

       
53
       
-
       
    <literal>extraDeps</literal> can be used, for example, to provide 

     

       
54
       
 
       
    <literal>xsel</literal> (a clipboard manager) to the clipboard plugin,

     

       
55
       
 
       
    without installing it globally:

     

       
56
       
 
       
    <programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {

     

···

       
50
       
 
       
    In addition to <literal>plugins</literal> the options

     

       
51
       
 
       
    <literal>extraDeps</literal> and <literal>perlDeps</literal> can be used

     

       
52
       
 
       
    to install extra packages.

     

       
53
       
+
       
    <literal>extraDeps</literal> can be used, for example, to provide

     

       
54
       
 
       
    <literal>xsel</literal> (a clipboard manager) to the clipboard plugin,

     

       
55
       
 
       
    without installing it globally:

     

       
56
       
 
       
    <programlisting>rxvt-unicode.override { configure = { availablePlugins, ... }: {

     

···

       
68
       
 
       
  <title>How to Install BEAM Packages</title>

     

       
69
       
 
       


     

       
70
       
 
       
  <para>

     

       
71
       
-
       
   BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users. 

     

       
72
       
 
       
   To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:

     

       
73
       
 
       
  </para>

     

       
74
       
 
       


     

···

       
68
       
 
       
  <title>How to Install BEAM Packages</title>

     

       
69
       
 
       


     

       
70
       
 
       
  <para>

     

       
71
       
+
       
   BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users.

     

       
72
       
 
       
   To install any of those builders into your profile, refer to them by their attribute path <literal>beamPackages.rebar3</literal>:

     

       
73
       
 
       
  </para>

     

       
74
       
 
       


     

···

       
21
       
 
       
* **Declarative usage**:

     

       
22
       
 
       


     

       
23
       
 
       
    This mode is far more power full since this makes use of `nix` for dependency management of emscripten libraries and targets by using the `mkDerivation` which is implemented by `pkgs.emscriptenStdenv` and `pkgs.buildEmscriptenPackage`. The source for the packages is in `pkgs/top-level/emscripten-packages.nix` and the abstraction behind it in `pkgs/development/em-modules/generic/default.nix`.

     

       
24
       
-
       
    * build and install all packages: 

     

       
25
       
-
       
        * `nix-env -iA emscriptenPackages` 

     

       
26
       
-
       
          

     

       
27
       
-
       
    * dev-shell for zlib implementation hacking: 

     

       
28
       
-
       
        * `nix-shell -A emscriptenPackages.zlib` 

     

       
29
       
 
       


     

       
30
       
 
       


     

       
31
       
 
       
## Imperative usage

     
···

       
90
       
 
       
        libz.so.${old.version} -I . -o example.js

     

       
91
       
 
       


     

       
92
       
 
       
        echo "Using node to execute the test"

     

       
93
       
-
       
        ${pkgs.nodejs}/bin/node ./example.js 

     

       
94
       
 
       


     

       
95
       
 
       
        set +x

     

       
96
       
 
       
        if [ $? -ne 0 ]; then

     
···

       
112
       
 
       


     

       
113
       
 
       
### Usage 2: pkgs.buildEmscriptenPackage

     

       
114
       
 
       


     

       
115
       
-
       
This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used. 

     

       
116
       
 
       


     

       
117
       
 
       
    xmlmirror = pkgs.buildEmscriptenPackage rec {

     

       
118
       
 
       
      name = "xmlmirror";

     
···

       
163
       
 
       
      checkPhase = ''

     

       
164
       
 
       


     

       
165
       
 
       
      '';

     

       
166
       
-
       
    }; 

     

       
167
       
 
       


     

       
168
       
 
       
### Declarative debugging

     

       
169
       
 
       


     
···

       
182
       
 
       
Using this toolchain makes it easy to leverage `nix` from NixOS, MacOSX or even Windows (WSL+ubuntu+nix). This toolchain is reproducible, behaves like the rest of the packages from nixpkgs and contains a set of well working examples to learn and adapt from.

     

       
183
       
 
       


     

       
184
       
 
       
If in trouble, ask the maintainers.

     

       
185
       
-
       


     

···

       
21
       
 
       
* **Declarative usage**:

     

       
22
       
 
       


     

       
23
       
 
       
    This mode is far more power full since this makes use of `nix` for dependency management of emscripten libraries and targets by using the `mkDerivation` which is implemented by `pkgs.emscriptenStdenv` and `pkgs.buildEmscriptenPackage`. The source for the packages is in `pkgs/top-level/emscripten-packages.nix` and the abstraction behind it in `pkgs/development/em-modules/generic/default.nix`.

     

       
24
       
+
       
    * build and install all packages:

     

       
25
       
+
       
        * `nix-env -iA emscriptenPackages`

     

       
26
       
+
       


     

       
27
       
+
       
    * dev-shell for zlib implementation hacking:

     

       
28
       
+
       
        * `nix-shell -A emscriptenPackages.zlib`

     

       
29
       
 
       


     

       
30
       
 
       


     

       
31
       
 
       
## Imperative usage

     
···

       
90
       
 
       
        libz.so.${old.version} -I . -o example.js

     

       
91
       
 
       


     

       
92
       
 
       
        echo "Using node to execute the test"

     

       
93
       
+
       
        ${pkgs.nodejs}/bin/node ./example.js

     

       
94
       
 
       


     

       
95
       
 
       
        set +x

     

       
96
       
 
       
        if [ $? -ne 0 ]; then

     
···

       
112
       
 
       


     

       
113
       
 
       
### Usage 2: pkgs.buildEmscriptenPackage

     

       
114
       
 
       


     

       
115
       
+
       
This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used.

     

       
116
       
 
       


     

       
117
       
 
       
    xmlmirror = pkgs.buildEmscriptenPackage rec {

     

       
118
       
 
       
      name = "xmlmirror";

     
···

       
163
       
 
       
      checkPhase = ''

     

       
164
       
 
       


     

       
165
       
 
       
      '';

     

       
166
       
+
       
    };

     

       
167
       
 
       


     

       
168
       
 
       
### Declarative debugging

     

       
169
       
 
       


     
···

       
182
       
 
       
Using this toolchain makes it easy to leverage `nix` from NixOS, MacOSX or even Windows (WSL+ubuntu+nix). This toolchain is reproducible, behaves like the rest of the packages from nixpkgs and contains a set of well working examples to learn and adapt from.

     

       
183
       
 
       


     

       
184
       
 
       
If in trouble, ask the maintainers.

     

       
0
       
 
       

     

···

       
72
       
 
       


     

       
73
       
 
       
    When `null` is used as a value, rather than fetching the dependencies

     

       
74
       
 
       
    and vendoring them, we use the vendoring included within the source repo.

     

       
75
       
-
       
    If you'd like to not have to update this field on dependency changes, 

     

       
76
       
 
       
    run `go mod vendor` in your source repo and set 'vendorSha256 = null;'

     

       
77
       
 
       
  </para>

     

       
78
       
 
       
 </section>

     

···

       
72
       
 
       


     

       
73
       
 
       
    When `null` is used as a value, rather than fetching the dependencies

     

       
74
       
 
       
    and vendoring them, we use the vendoring included within the source repo.

     

       
75
       
+
       
    If you'd like to not have to update this field on dependency changes,

     

       
76
       
 
       
    run `go mod vendor` in your source repo and set 'vendorSha256 = null;'

     

       
77
       
 
       
  </para>

     

       
78
       
 
       
 </section>

     

···

       
79
       
 
       


     

       
80
       
 
       
When using `buildRustPackage`, the `checkPhase` is enabled by default and runs

     

       
81
       
 
       
`cargo test` on the package to build. To make sure that we don't compile the

     

       
82
       
-
       
sources twice and to actually test the artifacts that will be used at runtime, 

     

       
83
       
 
       
the tests will be ran in the `release` mode by default.

     

       
84
       
 
       


     

       
85
       
 
       
However, in some cases the test-suite of a package doesn't work properly in the

     

···

       
79
       
 
       


     

       
80
       
 
       
When using `buildRustPackage`, the `checkPhase` is enabled by default and runs

     

       
81
       
 
       
`cargo test` on the package to build. To make sure that we don't compile the

     

       
82
       
+
       
sources twice and to actually test the artifacts that will be used at runtime,

     

       
83
       
 
       
the tests will be ran in the `release` mode by default.

     

       
84
       
 
       


     

       
85
       
 
       
However, in some cases the test-suite of a package doesn't work properly in the

     

···

       
220
       
 
       


     

       
221
       
 
       
preConfigure=preConfigure

     

       
222
       
 
       
preConfigure() {

     

       
223
       
-
       
    

     

       
224
       
 
       
    # Determine the frontends to build.

     

       
225
       
 
       
    langs="c"

     

       
226
       
 
       
    if test -n "$langCC"; then

     
···

       
262
       
 
       


     

       
263
       
 
       
#if test -z "$profiledCompiler"; then

     

       
264
       
 
       
    #makeFlags="bootstrap"

     

       
265
       
-
       
#else    

     

       
266
       
 
       
    #makeFlags="profiledbootstrap"

     

       
267
       
 
       
#fi

     

       
268
       
 
       


     

···

       
220
       
 
       


     

       
221
       
 
       
preConfigure=preConfigure

     

       
222
       
 
       
preConfigure() {

     

       
223
       
+
       


     

       
224
       
 
       
    # Determine the frontends to build.

     

       
225
       
 
       
    langs="c"

     

       
226
       
 
       
    if test -n "$langCC"; then

     
···

       
262
       
 
       


     

       
263
       
 
       
#if test -z "$profiledCompiler"; then

     

       
264
       
 
       
    #makeFlags="bootstrap"

     

       
265
       
+
       
#else

     

       
266
       
 
       
    #makeFlags="profiledbootstrap"

     

       
267
       
 
       
#fi

     

       
268