diff --git a/doc/builders/packages/citrix.xml b/doc/builders/packages/citrix.xml index 803eb2e4fc4..7a16b79f232 100644 --- a/doc/builders/packages/citrix.xml +++ b/doc/builders/packages/citrix.xml @@ -17,9 +17,11 @@
Citrix Selfservice + The selfservice is an application managing Citrix desktops and applications. Please note that this feature only works with at least citrix_workspace_20_06_0 and later versions. + In order to set this up, you first have to download the .cr file from the Netscaler Gateway. After that you can configure the selfservice like this: diff --git a/doc/contributing/coding-conventions.xml b/doc/contributing/coding-conventions.xml index 9005a9ebafd..9f00942918c 100644 --- a/doc/contributing/coding-conventions.xml +++ b/doc/contributing/coding-conventions.xml @@ -180,17 +180,12 @@ args.stdenv.mkDerivation (args // { - Arguments should be listed in the order they are used, with the - exception of lib, which always goes first. + Arguments should be listed in the order they are used, with the exception of lib, which always goes first. - Prefer using the top-level lib over its alias - stdenv.lib. lib is unrelated to - stdenv, and so stdenv.lib should only - be used as a convenience alias when developing to avoid having to modify - the function inputs just to test something out. + Prefer using the top-level lib over its alias stdenv.lib. lib is unrelated to stdenv, and so stdenv.lib should only be used as a convenience alias when developing to avoid having to modify the function inputs just to test something out. @@ -689,8 +684,7 @@ args.stdenv.mkDerivation (args // { - If it’s a theme for a desktop environment, - a window manager or a display manager: + If it’s a theme for a desktop environment, a window manager or a display manager: diff --git a/doc/functions/library/attrsets.xml b/doc/functions/library/attrsets.xml index 7ef0d16624c..9a4e640935f 100644 --- a/doc/functions/library/attrsets.xml +++ b/doc/functions/library/attrsets.xml @@ -1677,8 +1677,7 @@ recursiveUpdate - Make various Nix tools consider the contents of the resulting - attribute set when looking for what to build, find, etc. + Make various Nix tools consider the contents of the resulting attribute set when looking for what to build, find, etc. @@ -1720,7 +1719,7 @@ recursiveUpdate - Return the cartesian product of attribute set value combinations. + Return the cartesian product of attribute set value combinations. @@ -1749,5 +1748,4 @@ cartesianProductOfSets { a = [ 1 2 ]; b = [ 10 20 ]; } ]]>
- diff --git a/doc/stdenv/multiple-output.xml b/doc/stdenv/multiple-output.xml index f710a9959ad..5f2d2b8cfb9 100644 --- a/doc/stdenv/multiple-output.xml +++ b/doc/stdenv/multiple-output.xml @@ -26,7 +26,6 @@ A number of attributes can be used to work with a derivation with multiple outputs. The attribute outputs is a list of strings, which are the names of the outputs. For each of these names, an identically named attribute is created, corresponding to that output. The attribute meta.outputsToInstall is used to determine the default set of outputs to install when using the derivation name unqualified. -
Installing a split package diff --git a/doc/stdenv/stdenv.xml b/doc/stdenv/stdenv.xml index 21485425f26..b2004270e9b 100644 --- a/doc/stdenv/stdenv.xml +++ b/doc/stdenv/stdenv.xml @@ -1136,9 +1136,9 @@ preBuild = '' Variables controlling the install phase - + - dontInstall + dontInstall @@ -1839,10 +1839,7 @@ addEnvHooks "$hostOffset" myBashFunction - This setup hook moves any systemd user units installed in the lib - subdirectory into share. In addition, a link is provided from share to - lib for compatibility. This is needed for systemd to find user services - when installed into the user profile. + This setup hook moves any systemd user units installed in the lib subdirectory into share. In addition, a link is provided from share to lib for compatibility. This is needed for systemd to find user services when installed into the user profile. @@ -2022,8 +2019,7 @@ addEnvHooks "$hostOffset" myBashFunction This is a special setup hook which helps in packaging proprietary software in that it automatically tries to find missing shared library dependencies of ELF files based on the given buildInputs and nativeBuildInputs. - You can also specify a runtimeDependencies variable which lists dependencies to be unconditionally added to rpath of all executables. - This is useful for programs that use + You can also specify a runtimeDependencies variable which lists dependencies to be unconditionally added to rpath of all executables. This is useful for programs that use dlopen 3 to load libraries at runtime. diff --git a/doc/using/configuration.xml b/doc/using/configuration.xml index 8e63e0072c8..3ef39733458 100644 --- a/doc/using/configuration.xml +++ b/doc/using/configuration.xml @@ -170,7 +170,7 @@ - Note that allowlistedLicenses only applies to unfree licenses unless allowUnfree is enabled. It is not a generic allowlist for all types of licenses. blocklistedLicenses applies to all licenses. + Note that allowlistedLicenses only applies to unfree licenses unless allowUnfree is enabled. It is not a generic allowlist for all types of licenses. blocklistedLicenses applies to all licenses. diff --git a/doc/using/overlays.xml b/doc/using/overlays.xml index 8bda235d43d..1def8b06955 100644 --- a/doc/using/overlays.xml +++ b/doc/using/overlays.xml @@ -28,8 +28,7 @@ - NOTE: DO NOT USE THIS in nixpkgs. - Further overlays can be added by calling the pkgs.extend or pkgs.appendOverlays, although it is often preferable to avoid these functions, because they recompute the Nixpkgs fixpoint, which is somewhat expensive to do. + NOTE: DO NOT USE THIS in nixpkgs. Further overlays can be added by calling the pkgs.extend or pkgs.appendOverlays, although it is often preferable to avoid these functions, because they recompute the Nixpkgs fixpoint, which is somewhat expensive to do.
@@ -139,98 +138,72 @@ self: super:
- Using overlays to configure alternatives + Using overlays to configure alternatives + + + Certain software packages have different implementations of the same interface. Other distributions have functionality to switch between these. For example, Debian provides DebianAlternatives. Nixpkgs has what we call alternatives, which are configured through overlays. + + +
+ BLAS/LAPACK + - Certain software packages have different implementations of the - same interface. Other distributions have functionality to switch - between these. For example, Debian provides DebianAlternatives. - Nixpkgs has what we call alternatives, which - are configured through overlays. + In Nixpkgs, we have multiple implementations of the BLAS/LAPACK numerical linear algebra interfaces. They are: -
- BLAS/LAPACK + + + - In Nixpkgs, we have multiple implementations of the BLAS/LAPACK - numerical linear algebra interfaces. They are: + OpenBLAS - - - - OpenBLAS - - - The Nixpkgs attribute is openblas for - ILP64 (integer width = 64 bits) and - openblasCompat for LP64 (integer width = - 32 bits). openblasCompat is the default. - - - - - LAPACK - reference (also provides BLAS) - - - The Nixpkgs attribute is lapack-reference. - - - - - Intel - MKL (only works on the x86_64 architecture, unfree) - - - The Nixpkgs attribute is mkl. - - - - - + The Nixpkgs attribute is openblas for ILP64 (integer width = 64 bits) and openblasCompat for LP64 (integer width = 32 bits). openblasCompat is the default. + + + + + LAPACK reference (also provides BLAS) + + + The Nixpkgs attribute is lapack-reference. + + + + + Intel MKL (only works on the x86_64 architecture, unfree) + + + The Nixpkgs attribute is mkl. + + + + + BLIS - - - BLIS, available through the attribute - blis, is a framework for linear algebra kernels. In - addition, it implements the BLAS interface. - - - - - AMD - BLIS/LIBFLAME (optimized for modern AMD x86_64 CPUs) - - - The AMD fork of the BLIS library, with attribute - amd-blis, extends BLIS with optimizations for - modern AMD CPUs. The changes are usually submitted to - the upstream BLIS project after some time. However, AMD BLIS - typically provides some performance improvements on AMD Zen CPUs. - The complementary AMD LIBFLAME library, with attribute - amd-libflame, provides a LAPACK implementation. - - - - - Introduced in PR - #83888, we are able to override the blas - and lapack packages to use different implementations, - through the blasProvider and - lapackProvider argument. This can be used - to select a different provider. BLAS providers will have - symlinks in $out/lib/libblas.so.3 and - $out/lib/libcblas.so.3 to their respective - BLAS libraries. Likewise, LAPACK providers will have symlinks - in $out/lib/liblapack.so.3 and - $out/lib/liblapacke.so.3 to their respective - LAPACK libraries. For example, Intel MKL is both a BLAS and - LAPACK provider. An overlay can be created to use Intel MKL - that looks like: - + + BLIS, available through the attribute blis, is a framework for linear algebra kernels. In addition, it implements the BLAS interface. + + + + + AMD BLIS/LIBFLAME (optimized for modern AMD x86_64 CPUs) + + + The AMD fork of the BLIS library, with attribute amd-blis, extends BLIS with optimizations for modern AMD CPUs. The changes are usually submitted to the upstream BLIS project after some time. However, AMD BLIS typically provides some performance improvements on AMD Zen CPUs. The complementary AMD LIBFLAME library, with attribute amd-libflame, provides a LAPACK implementation. + + + + + + Introduced in PR #83888, we are able to override the blas and lapack packages to use different implementations, through the blasProvider and lapackProvider argument. This can be used to select a different provider. BLAS providers will have symlinks in $out/lib/libblas.so.3 and $out/lib/libcblas.so.3 to their respective BLAS libraries. Likewise, LAPACK providers will have symlinks in $out/lib/liblapack.so.3 and $out/lib/liblapacke.so.3 to their respective LAPACK libraries. For example, Intel MKL is both a BLAS and LAPACK provider. An overlay can be created to use Intel MKL that looks like: + + + self: super: { @@ -243,46 +216,24 @@ self: super: }; } - - This overlay uses Intel’s MKL library for both BLAS and LAPACK - interfaces. Note that the same can be accomplished at runtime - using LD_LIBRARY_PATH of - libblas.so.3 and - liblapack.so.3. For instance: - + + + This overlay uses Intel’s MKL library for both BLAS and LAPACK interfaces. Note that the same can be accomplished at runtime using LD_LIBRARY_PATH of libblas.so.3 and liblapack.so.3. For instance: + + $ LD_LIBRARY_PATH=$(nix-build -A mkl)/lib:$LD_LIBRARY_PATH nix-shell -p octave --run octave - - Intel MKL requires an openmp implementation - when running with multiple processors. By default, - mkl will use Intel’s iomp - implementation if no other is specified, but this is a - runtime-only dependency and binary compatible with the LLVM - implementation. To use that one instead, Intel recommends users - set it with LD_PRELOAD. Note that - mkl is only available on - x86_64-linux and - x86_64-darwin. Moreover, Hydra is not - building and distributing pre-compiled binaries using it. - - - 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 versions of BLAS/LAPACK currently - in the wild, LP64 (integer size = 32 bits) - and ILP64 (integer size = 64 bits). 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: - - + + + Intel MKL requires an openmp implementation when running with multiple processors. By default, mkl will use Intel’s iomp implementation if no other is specified, but this is a runtime-only dependency and binary compatible with the LLVM implementation. To use that one instead, Intel recommends users set it with LD_PRELOAD. Note that mkl is only available on x86_64-linux and x86_64-darwin. Moreover, Hydra is not building and distributing pre-compiled binaries using it. + + + + 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 versions of BLAS/LAPACK currently in the wild, LP64 (integer size = 32 bits) and ILP64 (integer size = 64 bits). 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: + + + { stdenv, blas, lapack, ... }: assert (!blas.isILP64) && (!lapack.isILP64); @@ -291,41 +242,38 @@ stdenv.mkDerivation { ... } -
-
- Switching the MPI implementation - - All programs that are built with - MPI - support use the generic attribute mpi - as an input. At the moment Nixpkgs natively provides two different - MPI implementations: - - - - Open MPI - (default), attribute name openmpi - - - - - MPICH, - attribute name mpich - - - - - - To provide MPI enabled applications that use MPICH, instead - of the default Open MPI, simply use the following overlay: - - +
+ +
+ Switching the MPI implementation + + + All programs that are built with MPI support use the generic attribute mpi as an input. At the moment Nixpkgs natively provides two different MPI implementations: + + + + Open MPI (default), attribute name openmpi + + + + + MPICH, attribute name mpich + + + + + + + To provide MPI enabled applications that use MPICH, instead of the default Open MPI, simply use the following overlay: + + + self: super: { mpi = self.mpich; } -
+