···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, ... }: {
+1-1
doc/languages-frameworks/beam.xml
···68 <title>How to Install BEAM Packages</title>
6970 <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>
6970 <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
+8-9
doc/languages-frameworks/emscripten.section.md
···21* **Declarative usage**:
2223 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`
293031## Imperative usage
···90 libz.so.${old.version} -I . -o example.js
9192 echo "Using node to execute the test"
93- ${pkgs.nodejs}/bin/node ./example.js
9495 set +x
96 if [ $? -ne 0 ]; then
···112113### Usage 2: pkgs.buildEmscriptenPackage
114115-This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used.
116117 xmlmirror = pkgs.buildEmscriptenPackage rec {
118 name = "xmlmirror";
···163 checkPhase = ''
164165 '';
166- };
167168### Declarative debugging
169···182Using 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.
183184If in trouble, ask the maintainers.
185-
···21* **Declarative usage**:
2223 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`
293031## Imperative usage
···90 libz.so.${old.version} -I . -o example.js
9192 echo "Using node to execute the test"
93+ ${pkgs.nodejs}/bin/node ./example.js
9495 set +x
96 if [ $? -ne 0 ]; then
···112113### Usage 2: pkgs.buildEmscriptenPackage
114115+This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used.
116117 xmlmirror = pkgs.buildEmscriptenPackage rec {
118 name = "xmlmirror";
···163 checkPhase = ''
164165 '';
166+ };
167168### Declarative debugging
169···182Using 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.
183184If in trouble, ask the maintainers.
0
+1-1
doc/languages-frameworks/go.xml
···7273 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>
···7273 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>
+1-1
doc/languages-frameworks/rust.section.md
···7980When 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,
83the tests will be ran in the `release` mode by default.
8485However, in some cases the test-suite of a package doesn't work properly in the
···7980When 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,
83the tests will be ran in the `release` mode by default.
8485However, in some cases the test-suite of a package doesn't work properly in the
+2-2
doc/old/cross.txt
···220221preConfigure=preConfigure
222preConfigure() {
223-224 # Determine the frontends to build.
225 langs="c"
226 if test -n "$langCC"; then
···262263#if test -z "$profiledCompiler"; then
264 #makeFlags="bootstrap"
265-#else
266 #makeFlags="profiledbootstrap"
267#fi
268
···220221preConfigure=preConfigure
222preConfigure() {
223+224 # Determine the frontends to build.
225 langs="c"
226 if test -n "$langCC"; then
···262263#if test -z "$profiledCompiler"; then
264 #makeFlags="bootstrap"
265+#else
266 #makeFlags="profiledbootstrap"
267#fi
268