+12
-3
doc/build-helpers/dev-shell-tools.chapter.md
+12
-3
doc/build-helpers/dev-shell-tools.chapter.md
······
+12
-5
doc/build-helpers/fetchers.chapter.md
+12
-5
doc/build-helpers/fetchers.chapter.md
···In this example, we'll adapt [](#ex-fetchers-fetchurl-nixpkgs-version) to append the result of running the `hello` package to the contents we download, purely to illustrate how to manipulate the content.······
+6
-3
doc/build-helpers/images/appimagetools.section.md
+6
-3
doc/build-helpers/images/appimagetools.section.md
···url = "https://github.com/irccloud/irccloud-desktop/releases/download/v${version}/IRCCloud-${version}-linux-x86_64.AppImage";······
+1
-1
doc/build-helpers/images/binarycache.section.md
+1
-1
doc/build-helpers/images/binarycache.section.md
+34
-8
doc/build-helpers/images/dockertools.section.md
+34
-8
doc/build-helpers/images/dockertools.section.md
·········This works the same as [](#ex-dockerTools-buildImage-extraCommands), but uses `runAsRoot` instead of `extraCommands`.···Note that with `extraCommands`, we can't directly reference `/` and must create files and directories as if we were already on `/`.······The following package shows a more compact way to create the same output generated in [](#ex-dockerTools-streamLayeredImage-hello).···
+37
-30
doc/build-helpers/images/makediskimage.section.md
+37
-30
doc/build-helpers/images/makediskimage.section.md
······
+5
-1
doc/build-helpers/images/ocitools.section.md
+5
-1
doc/build-helpers/images/ocitools.section.md
+17
-3
doc/build-helpers/images/portableservice.section.md
+17
-3
doc/build-helpers/images/portableservice.section.md
···The following example builds a Portable Service image with the `hello` package, along with a service unit that runs it.···The following package builds on the package from [](#ex-portableService-hello) to make `/etc/ssl` available globally (this is only for illustrative purposes, because `hello` doesn't use `/etc/ssl`).···
+5
-2
doc/build-helpers/special/checkpoint-build.section.md
+5
-2
doc/build-helpers/special/checkpoint-build.section.md
······
+11
-4
doc/build-helpers/special/fakenss.section.md
+11
-4
doc/build-helpers/special/fakenss.section.md
···This example includes the `hello` binary in the image so it can do something besides just have the extra files.···
+20
-13
doc/build-helpers/special/fhs-environments.section.md
+20
-13
doc/build-helpers/special/fhs-environments.section.md
···
+7
-2
doc/build-helpers/special/mkshell.section.md
+7
-2
doc/build-helpers/special/mkshell.section.md
···
+30
-19
doc/build-helpers/special/vm-tools.section.md
+30
-19
doc/build-helpers/special/vm-tools.section.md
···Use VM with a disk image (implicitly sets `diskImage`, see [`vmTools.createEmptyImage`](#vm-tools-createEmptyImage)):·········
+64
-40
doc/build-helpers/testers.chapter.md
+64
-40
doc/build-helpers/testers.chapter.md
···-"https://nixos\\.org/manual/nix/(un)?stable" = "${emptyDirectory}/placeholder-to-disallow-old-nix-docs-urls";·········+testers.testEqualDerivation "The hello package must stay the same when enabling checks." hello (·········
+84
-57
doc/build-helpers/trivial-build-helpers.chapter.md
+84
-57
doc/build-helpers/trivial-build-helpers.chapter.md
························Write the string `Contents of File` to `/nix/store/<store path>` and make the file executable.··················-symlinkJoin { name = "myexample"; paths = [ pkgs.hello pkgs.stack ]; postBuild = "echo links added"; }
+13
-7
doc/functions/generators.section.md
+13
-7
doc/functions/generators.section.md
···
+13
-10
doc/functions/nix-gitignore.section.md
+13
-10
doc/functions/nix-gitignore.section.md
···`pkgs.nix-gitignore` exports a number of functions, but you'll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.+src = nix-gitignore.gitignoreSourcePure [ "ignore-this\nignore-that\n" ~/.gitignore ] ./source;
+1
-2
doc/functions/prefer-remote-fetch.section.md
+1
-2
doc/functions/prefer-remote-fetch.section.md
···`prefer-remote-fetch` is an overlay that download sources on remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster directly from the source. To use it, put the following snippet as a new overlay:
+8
-8
doc/hooks/mpi-check-hook.section.md
+8
-8
doc/hooks/mpi-check-hook.section.md
···
+12
-2
doc/hooks/patch-rc-path-hooks.section.md
+12
-2
doc/hooks/patch-rc-path-hooks.section.md
···patch the init script for users to source without having the above dependencies in their `PATH`:···
+10
-6
doc/hooks/postgresql-test-hook.section.md
+10
-6
doc/hooks/postgresql-test-hook.section.md
······
+7
-2
doc/hooks/redis-test-hook.section.md
+7
-2
doc/hooks/redis-test-hook.section.md
·········
+1
-1
doc/hooks/versionCheckHook.section.md
+1
-1
doc/hooks/versionCheckHook.section.md
+4
-3
doc/hooks/zig.section.md
+4
-3
doc/hooks/zig.section.md
+13
-3
doc/interoperability/cyclonedx.md
+13
-3
doc/interoperability/cyclonedx.md
···`nix:fod` properties may be extracted and evaluated to a derivation using code similar to the following, assuming a fictitious function `filterPropertiesToAttrs`:
+14
-6
doc/languages-frameworks/agda.section.md
+14
-6
doc/languages-frameworks/agda.section.md
············To add an Agda package to `nixpkgs`, the derivation should be written to `pkgs/development/libraries/agda/${library-name}/` and an entry should be added to `pkgs/top-level/agda-packages.nix`. Here it is called in a scope with access to all other Agda libraries, so the top line of the `default.nix` can look like:
+24
-16
doc/languages-frameworks/android.section.md
+24
-16
doc/languages-frameworks/android.section.md
············Alternatively, you can deploy the SDK separately with a desired set of plugins, or subsets of an SDK.··················
+67
-33
doc/languages-frameworks/beam.section.md
+67
-33
doc/languages-frameworks/beam.section.md
·········mixEnv = ""; # default is "prod", when empty includes all dependencies, such as "dev", "test".·········Usually, we need to create a `shell.nix` file and do our development inside of the environment specified therein. Just install your version of Erlang and any other interpreters, and then use your normal build tools. As an example with Elixir:·········
+17
-8
doc/languages-frameworks/bower.section.md
+17
-8
doc/languages-frameworks/bower.section.md
···-(fetchbower "bootstrap" "3.3.6" "~3.3.6" "1vvqlpbfcy0k5pncfjaiskj3y6scwifxygfqnw393sjfxiviwmbv")-(fetchbower "jquery" "2.2.2" "1.9.1 - 2" "10sp5h98sqwk90y4k6hbdviwqzvzwqf47r3r51pakch5ii2y7js1")+(fetchbower "bootstrap" "3.3.6" "~3.3.6" "1vvqlpbfcy0k5pncfjaiskj3y6scwifxygfqnw393sjfxiviwmbv")+(fetchbower "jquery" "2.2.2" "1.9.1 - 2" "10sp5h98sqwk90y4k6hbdviwqzvzwqf47r3r51pakch5ii2y7js1")Using the `bower2nix` command line arguments, the output can be redirected to a file. A name like `bower-packages.nix` would be fine.······
+12
-8
doc/languages-frameworks/chicken.section.md
+12
-8
doc/languages-frameworks/chicken.section.md
···
+70
-27
doc/languages-frameworks/coq.section.md
+70
-27
doc/languages-frameworks/coq.section.md
···Here is a simple package example. It is a pure Coq library, thus it depends on Coq. It builds on the Mathematical Components library, thus it also takes some `mathcomp` derivations as `extraBuildInputs`.···For example, here is how you could locally add a new release of the `multinomials` library, and set the `defaultVersion` to use this release:···
+6
-3
doc/languages-frameworks/crystal.section.md
+6
-3
doc/languages-frameworks/crystal.section.md
···Next create a Nix file for your derivation and use `pkgs.crystal.buildCrystalPackage` as follows:···Depending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:
+16
-10
doc/languages-frameworks/cuda.section.md
+16
-10
doc/languages-frameworks/cuda.section.md
···To use one or more CUDA packages in an expression, give the expression a `cudaPackages` parameter, and in case CUDA is optional···
+12
-14
doc/languages-frameworks/cuelang.section.md
+12
-14
doc/languages-frameworks/cuelang.section.md
······
+6
-2
doc/languages-frameworks/dart.section.md
+6
-2
doc/languages-frameworks/dart.section.md
···Dart supports multiple [outputs types](https://dart.dev/tools/dart-compile#types-of-output), you can choose between them using `dartOutputType` (defaults to `exe`). If you want to override the binaries path or the source path they come from, you can use `dartEntryPoints`. Outputs that require a runtime will automatically be wrapped with the relevant runtime (`dartaotruntime` for `aot-snapshot`, `dart run` for `jit-snapshot` and `kernel`, `node` for `js`), this can be overridden through `dartRuntimeCommand`.···`flutter` in Nixpkgs always points to `flutterPackages.stable`, which is the latest packaged version. To avoid unforeseen breakage during upgrade, packages in Nixpkgs should use a specific flutter version, such as `flutter319` and `flutter322`, instead of using `flutter` directly.
+8
-7
doc/languages-frameworks/dhall.section.md
+8
-7
doc/languages-frameworks/dhall.section.md
···-url = "https://github.com/NixOS/nixpkgs/archive/94b2848559b12a8ed1fe433084686b2a81123c99.tar.gz";+url = "https://github.com/NixOS/nixpkgs/archive/94b2848559b12a8ed1fe433084686b2a81123c99.tar.gz";······
+21
-10
doc/languages-frameworks/dotnet.section.md
+21
-10
doc/languages-frameworks/dotnet.section.md
······It's very likely that more than one sdk will be needed on a given project. Dotnet provides several different frameworks (E.g dotnetcore, aspnetcore, etc.) as well as many versions for a given framework. Normally, dotnet is able to fetch a framework and install it relative to the executable. However, this would mean writing to the nix store in nixpkgs, which is read-only. To support the many-sdk use case, one can compose an environment using `dotnetCorePackages.combinePackages`:······
+65
-47
doc/languages-frameworks/emscripten.section.md
+65
-47
doc/languages-frameworks/emscripten.section.md
·········
+6
-1
doc/languages-frameworks/gnome.section.md
+6
-1
doc/languages-frameworks/gnome.section.md
···--prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
+10
-6
doc/languages-frameworks/gradle.section.md
+10
-6
doc/languages-frameworks/gradle.section.md
······
+2
-1
doc/languages-frameworks/hare.section.md
+2
-1
doc/languages-frameworks/hare.section.md
+85
-63
doc/languages-frameworks/haskell.section.md
+85
-63
doc/languages-frameworks/haskell.section.md
··················+pkgs.haskell.lib.overrideCabal (pkgs.haskell.lib.justStaticExecutables my-haskell-package) (drv: {···+pkgs.haskell.lib.overrideCabal (pkgs.haskell.lib.justStaticExecutables my-haskell-package) (drv: {······
+8
-2
doc/languages-frameworks/hy.section.md
+8
-2
doc/languages-frameworks/hy.section.md
···
+24
-11
doc/languages-frameworks/idris.section.md
+24
-11
doc/languages-frameworks/idris.section.md
······As an example of how a Nix expression for an Idris package can be created, here is the one for `idrisPackages.yaml`:·········
+34
-23
doc/languages-frameworks/idris2.section.md
+34
-23
doc/languages-frameworks/idris2.section.md
···A simple example of a fully packaged library would be the [`LSP-lib`](https://github.com/idris-community/LSP-lib) found in the `idris-community` GitHub organization.A slightly more involved example of a fully packaged executable would be the [`idris2-lsp`](https://github.com/idris-community/idris2-lsp) which is an Idris2 language server that uses the `LSP-lib` found above.The above uses the default value of `withSource = false` for the `idris2Api` but could be modified to include that library's source by passing `(idris2Api { withSource = true; })` to `idrisLibraries` instead. `idris2Api` in the above derivation comes built in with `idris2Packages`. This library exposes many of the otherwise internal APIs of the Idris2 compiler.
+4
-4
doc/languages-frameworks/ios.section.md
+4
-4
doc/languages-frameworks/ios.section.md
············
+8
-3
doc/languages-frameworks/java.section.md
+8
-3
doc/languages-frameworks/java.section.md
·········
+45
-28
doc/languages-frameworks/javascript.section.md
+45
-28
doc/languages-frameworks/javascript.section.md
···For example, `dat` requires `node-gyp-build`, so we override its expression in [pkgs/development/node-packages/overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/overrides.nix):### Adding and Updating Javascript packages in nixpkgs {#javascript-adding-or-updating-packages}·····················
+3
-2
doc/languages-frameworks/julia.section.md
+3
-2
doc/languages-frameworks/julia.section.md
······
+13
-6
doc/languages-frameworks/lisp.section.md
+13
-6
doc/languages-frameworks/lisp.section.md
·········
+45
-17
doc/languages-frameworks/lua.section.md
+45
-17
doc/languages-frameworks/lua.section.md
·········For the sake of completeness, here's another example how to install the environment system-wide.·········-url = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";+url = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";···Using the `withPackages` function, the previous example for the luafilesystem environment can be written like this:`withPackages` passes the correct package set for the specific interpreter version as an argument to the function. In the above example, `ps` equals `luaPackages`.
+46
-15
doc/languages-frameworks/maven.section.md
+46
-15
doc/languages-frameworks/maven.section.md
······Here is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/build-maven-repository.nix) of building the Maven repository·········+src = builtins.fetchTarball "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";···We will modify the derivation above to add a symlink to our repository so that it's accessible to our JAR during the `installPhase`.+src = builtins.fetchTarball "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
+4
-4
doc/languages-frameworks/neovim.section.md
+4
-4
doc/languages-frameworks/neovim.section.md
······
+29
-13
doc/languages-frameworks/nim.section.md
+29
-13
doc/languages-frameworks/nim.section.md
·········For example, to propagate a dependency on SDL2 for lockfiles that select the Nim `sdl2` library, an overlay is added to the set in the `nim-overrides.nix` file:···
+30
-13
doc/languages-frameworks/ocaml.section.md
+30
-13
doc/languages-frameworks/ocaml.section.md
···············Here is a second example, this time using a source archive generated with `dune-release`. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a `%%VERSION%%` field. This library does not depend on any other OCaml library and no tests are run after building it.
+3
-1
doc/languages-frameworks/octave.section.md
+3
-1
doc/languages-frameworks/octave.section.md
+20
-4
doc/languages-frameworks/perl.section.md
+20
-4
doc/languages-frameworks/perl.section.md
······`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`:······On Darwin, if a script has too many `-Idir` flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the `shortenPerlShebang` function from the `postInstall` phase:
+91
-48
doc/languages-frameworks/php.section.md
+91
-48
doc/languages-frameworks/php.section.md
························
+6
-3
doc/languages-frameworks/pkg-config.section.md
+6
-3
doc/languages-frameworks/pkg-config.section.md
······
+234
-160
doc/languages-frameworks/python.section.md
+234
-160
doc/languages-frameworks/python.section.md
························Note that overriding packages deeper in the dependency graph _can_ work, but it's not the primary use case and overriding existing packages can make others break in unexpected ways.··················In contrast to [`python.buildEnv`](#python.buildenv-function), [`python.withPackages`](#python.withpackages-function) does not support the························when building the bindings and are therefore added as [`buildInputs`](#var-stdenv-buildInputs).······description = "Pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms";·····················### `python setup.py bdist_wheel` cannot create .whl {#python-setup.py-bdist_wheel-cannot-create-.whl}············
+6
-2
doc/languages-frameworks/qt.section.md
+6
-2
doc/languages-frameworks/qt.section.md
···The `makeWrapper` arguments required for Qt are also exposed in the environment as `$qtWrapperArgs`.
+34
-22
doc/languages-frameworks/r.section.md
+34
-22
doc/languages-frameworks/r.section.md
············
+59
-16
doc/languages-frameworks/ruby.section.md
+59
-16
doc/languages-frameworks/ruby.section.md
······With this file in your directory, you can run `nix-shell` to build and use the gems. The important parts here are `bundlerEnv` and `wrappedRuby`.···Sometimes a Gemfile references other files. Such as `.ruby-version` or vendored gems. When copying the Gemfile to the nix store we need to copy those files alongside. This can be done using `extraConfigPaths`. For example:···+buildFlags = [ "--with-pg-config=${pkgs."postgresql_${pg_version}".pg_config}/bin/pg_config" ];+buildFlags = [ "--with-pg-config=${pkgs."postgresql_${pg_version}".pg_config}/bin/pg_config" ];···Then we can get whichever postgresql version we desire and the `pg` gem will always reference it correctly:······
+127
-92
doc/languages-frameworks/rust.section.md
+127
-92
doc/languages-frameworks/rust.section.md
·············································Some projects, especially GNOME applications, are built with the Meson Build System instead of calling Cargo directly. Using `rustPlatform.buildRustPackage` may successfully build the main program, but related files will be missing. Instead, you need to set up Cargo dependencies with `fetchCargoVendor` and `cargoSetupHook` and leave the rest to Meson. `rust` and `cargo` are still needed in `nativeBuildInputs` for Meson to use.························The below snippet demonstrates invoking `buildRustPackage` with a Rust toolchain from oxalica's overlay:······
+11
-2
doc/languages-frameworks/swift.section.md
+11
-2
doc/languages-frameworks/swift.section.md
······
+59
-33
doc/languages-frameworks/texlive.section.md
+59
-33
doc/languages-frameworks/texlive.section.md
···- Packages cannot be used directly but must be assembled in an environment. To create or add packages to an environment, use···- `texlive.withPackages` uses the same logic as `buildEnv`. Only parts of a package are installed in an environment: its 'runtime' files (`tex` output), binaries (`out` output), and support files (`tlpkg` output). Moreover, man and info pages are assembled into separate `man` and `info` outputs. To add only the TeX files of a package, or its documentation (`texdoc` output), just specify the outputs:- All packages distributed by TeX Live, which contains most of CTAN, are available and can be found under `texlive.pkgs`:·········Here is a (very verbose) example. See also the packages `auctex`, `eukleides`, `mftrace` for more examples.·········Therefore, it is necessary to set `$HOME` to a writable path, e.g. [before using LuaLaTeX in nix derivations](https://github.com/NixOS/nixpkgs/issues/180639):-env HOME=$(mktemp -d) lualatex -interaction=nonstopmode -output-format=pdf -output-directory=$out ./main.tex+env HOME=$(mktemp -d) lualatex -interaction=nonstopmode -output-format=pdf -output-directory=$out ./main.tex
+36
-25
doc/languages-frameworks/vim.section.md
+36
-25
doc/languages-frameworks/vim.section.md
··················
+43
-37
doc/packages/cataclysm-dda.section.md
+43
-37
doc/packages/cataclysm-dda.section.md
············
+2
-1
doc/packages/citrix.section.md
+2
-1
doc/packages/citrix.section.md
+72
-58
doc/packages/darwin-builder.section.md
+72
-58
doc/packages/darwin-builder.section.md
······
+35
-31
doc/packages/eclipse.section.md
+35
-31
doc/packages/eclipse.section.md
······
+85
-76
doc/packages/emacs.section.md
+85
-76
doc/packages/emacs.section.md
·········
+6
-3
doc/packages/fish.section.md
+6
-3
doc/packages/fish.section.md
···
+10
-3
doc/packages/ibus.section.md
+10
-3
doc/packages/ibus.section.md
···On NixOS, you need to explicitly enable `ibus` with given engines before customizing your desktop to use `typing-booster`. This can be achieved using the `ibus` module:···The IBus engine is based on `hunspell` to support completion in many languages. By default, the dictionaries `de-de`, `en-us`, `fr-moderne` `es-es`, `it-it`, `sv-se` and `sv-fi` are in use. To add another dictionary, the package can be overridden like this:···
+1
-1
doc/packages/krita.section.md
+1
-1
doc/packages/krita.section.md
+9
-5
doc/packages/python-tree-sitter.section.md
+9
-5
doc/packages/python-tree-sitter.section.md
···For example, to experiment with the Rust grammar, you can create a shell environment with the following configuration:
+24
-12
doc/packages/urxvt.section.md
+24
-12
doc/packages/urxvt.section.md
············
+63
-27
doc/packages/weechat.section.md
+63
-27
doc/packages/weechat.section.md
···WeeChat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration, such as:···The Python and Perl plugins allows the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:···In order to also keep all default plugins installed, it is possible to use the following method:WeeChat allows to set defaults on startup using the `--run-command`. The `configure` method can be used to pass commands to the program:······
+14
-6
doc/stdenv/cross-compilation.chapter.md
+14
-6
doc/stdenv/cross-compilation.chapter.md
···In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like:···
+7
-2
doc/stdenv/meta.chapter.md
+7
-2
doc/stdenv/meta.chapter.md
······
+6
-1
doc/stdenv/multiple-output.chapter.md
+6
-1
doc/stdenv/multiple-output.chapter.md
+3
-1
doc/stdenv/passthru.chapter.md
+3
-1
doc/stdenv/passthru.chapter.md
+47
-27
doc/stdenv/stdenv.chapter.md
+47
-27
doc/stdenv/stdenv.chapter.md
··················Unlike the `pkg` binding in the above example, the `finalAttrs` parameter always references the final attributes. For instance `(pkg.overrideAttrs(x)).finalAttrs.finalPackage` is identical to `pkg.overrideAttrs(x)`, whereas `(pkg.overrideAttrs(x)).original` is the same as the original `pkg`.······
+166
-121
doc/using/configuration.chapter.md
+166
-121
doc/using/configuration.chapter.md
···························-export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin-export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man+export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin+export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man···-export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin-export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man-export INFOPATH=$HOME/.nix-profile/share/info:/nix/var/nix/profiles/default/share/info:/usr/share/info+export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin+export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man+export INFOPATH=$HOME/.nix-profile/share/info:/nix/var/nix/profiles/default/share/info:/usr/share/info
+6
-1
doc/using/overlays.chapter.md
+6
-1
doc/using/overlays.chapter.md
···For BLAS/LAPACK switching to work correctly, all packages must depend on `blas` or `lapack`. This ensures that only one BLAS/LAPACK library is used at one time. There are two versions of BLAS/LAPACK currently in the wild, `LP64` (integer size = 32 bits) and `ILP64` (integer size = 64 bits). The attributes `blas` and `lapack` are `LP64` by default. Their `ILP64` version are provided through the attributes `blas-ilp64` and `lapack-ilp64`. Some software needs special flags or patches to work with `ILP64`. You can check if `ILP64` is used in Nixpkgs with `blas.isILP64` and `lapack.isILP64`. Some software does NOT work with `ILP64`, and derivations need to specify an assertion to prevent this. You can prevent `ILP64` from being used with the following:
+32
-12
doc/using/overrides.chapter.md
+32
-12
doc/using/overrides.chapter.md
···<!-- TODO: move below programlisting to a new section about extending and overlays and reference it -->·········