doc/*: editorconfig fixes

zowoq b3d71cd6 af2055de

+14 -15
+1 -1
doc/builders/packages/urxvt.xml
··· 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> 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
+8 -9
doc/languages-frameworks/emscripten.section.md
··· 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.
+1 -1
doc/languages-frameworks/go.xml
··· 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>
+1 -1
doc/languages-frameworks/rust.section.md
··· 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
+2 -2
doc/old/cross.txt
··· 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