mirror of
https://github.com/ilyakooo0/nixpkgs.git
synced 2024-08-17 03:00:51 +03:00
doc: fix typos
This commit is contained in:
parent
42600bc715
commit
403e25e3e3
@ -185,7 +185,7 @@ Sample template for a new module review is provided below.
|
||||
##### Comments
|
||||
```
|
||||
|
||||
## Individual maintainer list {#reviewing-contributions-indvidual-maintainer-list}
|
||||
## Individual maintainer list {#reviewing-contributions-individual-maintainer-list}
|
||||
|
||||
When adding users to `maintainers/maintainer-list.nix`, the following
|
||||
checks should be performed:
|
||||
|
@ -1,4 +1,4 @@
|
||||
# Generates the documentation for library functons via nixdoc. To add
|
||||
# Generates the documentation for library functions via nixdoc. To add
|
||||
# another library function file to this list, the include list in the
|
||||
# file `doc/functions/library.xml` must also be updated.
|
||||
|
||||
|
@ -93,7 +93,7 @@ Practical steps:
|
||||
- run `mix2nix > mix_deps.nix` in the upstream repo.
|
||||
- pass `mixNixDeps = with pkgs; import ./mix_deps.nix { inherit lib beamPackages; };` as an argument to mixRelease.
|
||||
|
||||
If there are git depencencies.
|
||||
If there are git dependencies.
|
||||
|
||||
- You'll need to fix the version artificially in mix.exs and regenerate the mix.lock with fixed version (on upstream). This will enable you to run `mix2nix > mix_deps.nix`.
|
||||
- From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.
|
||||
|
@ -8,7 +8,7 @@ The Coq derivation is overridable through the `coq.override overrides`, where ov
|
||||
* `customOCamlPackages` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).
|
||||
* `coq-version` (optional, defaults to the short version e.g. "8.10"), is a version number of the form "x.y" that indicates which Coq's version build behavior to mimic when using a source which is not a release. E.g. `coq.override { version = "d370a9d1328a4e1cdb9d02ee032f605a9d94ec7a"; coq-version = "8.10"; }`.
|
||||
|
||||
The associated package set can be optained using `mkCoqPackages coq`, where `coq` is the derivation to use.
|
||||
The associated package set can be obtained using `mkCoqPackages coq`, where `coq` is the derivation to use.
|
||||
|
||||
## Coq packages attribute sets: `coqPackages` {#coq-packages-attribute-sets-coqpackages}
|
||||
|
||||
|
@ -38,7 +38,7 @@ want to target for in terms of SASS (real hardware) or PTX (JIT kernels).
|
||||
|
||||
Nixpkgs tries to target support real architecture defaults based on the
|
||||
CUDA toolkit version with PTX support for future hardware. Experienced
|
||||
users may optmize this configuration for a variety of reasons such as
|
||||
users may optimize this configuration for a variety of reasons such as
|
||||
reducing binary size and compile time, supporting legacy hardware, or
|
||||
optimizing for specific hardware.
|
||||
|
||||
|
@ -37,9 +37,9 @@ pkgs.writeCueValidator
|
||||
```
|
||||
|
||||
- The first parameter is the Cue schema file.
|
||||
- The second paramter is an options parameter, currently, only: `document` can be passed.
|
||||
- The second parameter is an options parameter, currently, only: `document` can be passed.
|
||||
|
||||
`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but differents documents based on the data you are validating.
|
||||
`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but different documents based on the data you are validating.
|
||||
|
||||
Another example, given the following `validator.nix` :
|
||||
```
|
||||
|
@ -4,10 +4,10 @@
|
||||
|
||||
### Installation without packages {#installation-without-packages}
|
||||
|
||||
You can install `hy` via nix-env or by adding it to `configuration.nix` by reffering to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it succesfully works with `python3`.
|
||||
You can install `hy` via nix-env or by adding it to `configuration.nix` by referring to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it successfully works with `python3`.
|
||||
|
||||
::: {.caution}
|
||||
Packages that are installed with your python derivation, are not accesible by `hy` this way.
|
||||
Packages that are installed with your python derivation, are not accessible by `hy` this way.
|
||||
:::
|
||||
|
||||
### Installation with packages {#installation-with-packages}
|
||||
|
@ -3,7 +3,7 @@
|
||||
xml:id="chap-language-support">
|
||||
<title>Languages and frameworks</title>
|
||||
<para>
|
||||
The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accomodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
|
||||
The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accommodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
|
||||
</para>
|
||||
<xi:include href="agda.section.xml" />
|
||||
<xi:include href="android.section.xml" />
|
||||
|
@ -605,7 +605,7 @@ been removed, in this case, it's recommended to use `pytestCheckHook`.
|
||||
`test` command for a `checkPhase` which runs `pytest`. This is also beneficial
|
||||
when a package may need many items disabled to run the test suite.
|
||||
|
||||
Using the example above, the analagous `pytestCheckHook` usage would be:
|
||||
Using the example above, the analogous `pytestCheckHook` usage would be:
|
||||
|
||||
```
|
||||
checkInputs = [ pytestCheckHook ];
|
||||
@ -624,7 +624,7 @@ Using the example above, the analagous `pytestCheckHook` usage would be:
|
||||
];
|
||||
```
|
||||
|
||||
This is expecially useful when tests need to be conditionally disabled,
|
||||
This is especially useful when tests need to be conditionally disabled,
|
||||
for example:
|
||||
|
||||
```
|
||||
|
@ -319,7 +319,7 @@ The above are just guidelines, and exceptions may be granted on a case-by-case b
|
||||
However, please check if it's possible to disable a problematic subset of the
|
||||
test suite and leave a comment explaining your reasoning.
|
||||
|
||||
This can be achived with `--skip` in `checkFlags`:
|
||||
This can be achieved with `--skip` in `checkFlags`:
|
||||
|
||||
```nix
|
||||
rustPlatform.buildRustPackage {
|
||||
|
@ -303,7 +303,7 @@ One of the compiler flags that GCC uses for this compiler is called X_CFLAGS.
|
||||
This is used by the Nix build process to set the dynamic linker, glibc
|
||||
in the case of i686-linux using the default Nix packages collection.
|
||||
|
||||
Obiously, since we need to compile libstc++ for arm-linux with uClibc linking
|
||||
Obviously, since we need to compile libstc++ for arm-linux with uClibc linking
|
||||
will not be done correctly: you can't link object files built for arm-linux
|
||||
with a glibc built for i686-linux.
|
||||
|
||||
|
@ -29,7 +29,7 @@ NixOS provides two ways to select the outputs to install for packages listed in
|
||||
`nix-env` lacks an easy way to select the outputs to install. When installing a package, `nix-env` always installs the outputs listed in `meta.outputsToInstall`, even when the user explicitly selects an output.
|
||||
|
||||
::: {.warning}
|
||||
`nix-env` silenty disregards the outputs selected by the user, and instead installs the outputs from `meta.outputsToInstall`. For example,
|
||||
`nix-env` silently disregards the outputs selected by the user, and instead installs the outputs from `meta.outputsToInstall`. For example,
|
||||
|
||||
```ShellSession
|
||||
$ nix-env -iA nixpkgs.coreutils.info
|
||||
|
@ -719,11 +719,11 @@ If set, libraries and executables are not stripped. By default, they are.
|
||||
|
||||
##### `dontStripHost` {#var-stdenv-dontStripHost}
|
||||
|
||||
Like `dontStrip`, but only affects the `strip` command targetting the package’s host platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
|
||||
Like `dontStrip`, but only affects the `strip` command targeting the package’s host platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
|
||||
|
||||
##### `dontStripTarget` {#var-stdenv-dontStripTarget}
|
||||
|
||||
Like `dontStrip`, but only affects the `strip` command targetting the packages’ target platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
|
||||
Like `dontStrip`, but only affects the `strip` command targeting the packages’ target platform. Useful when supporting cross compilation, but otherwise feel free to ignore.
|
||||
|
||||
##### `dontMoveSbin` {#var-stdenv-dontMoveSbin}
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user