Merge master into staging-next
This commit is contained in:
@@ -12,8 +12,8 @@
|
||||
|
||||
<para>
|
||||
Some extensions (plugins) might require OCaml and sometimes other OCaml
|
||||
packages. The <literal>coq.ocamlPackages</literal> attribute can be used
|
||||
to depend on the same package set Coq was built against.
|
||||
packages. The <literal>coq.ocamlPackages</literal> attribute can be used to
|
||||
depend on the same package set Coq was built against.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
||||
@@ -23,6 +23,7 @@ Adding custom .vimrc lines can be done using the following code:
|
||||
|
||||
```
|
||||
vim_configurable.customize {
|
||||
# `name` specifies the name of the executable and package
|
||||
name = "vim-with-plugins";
|
||||
|
||||
vimrcConfig.customRC = ''
|
||||
@@ -31,6 +32,8 @@ vim_configurable.customize {
|
||||
}
|
||||
```
|
||||
|
||||
This configuration is used when vim is invoked with the command specified as name, in this case `vim-with-plugins`.
|
||||
|
||||
For Neovim the `configure` argument can be overridden to achieve the same:
|
||||
|
||||
```
|
||||
@@ -83,6 +86,7 @@ The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.n
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; {
|
||||
myVim = vim_configurable.customize {
|
||||
# `name` specifies the name of the executable and package
|
||||
name = "vim-with-plugins";
|
||||
# add here code from the example section
|
||||
};
|
||||
|
||||
@@ -372,7 +372,7 @@ let f(h, h + 1, i) = i + h
|
||||
They are programs/libraries used at build time that furthermore produce
|
||||
programs/libraries also used at build time. If the dependency doesn't
|
||||
care about the target platform (i.e. isn't a compiler or similar tool),
|
||||
put it in <varname>nativeBuildInputs</varname>instead. The most common
|
||||
put it in <varname>nativeBuildInputs</varname> instead. The most common
|
||||
use for this <literal>buildPackages.stdenv.cc</literal>, the default C
|
||||
compiler for this role. That example crops up more than one might think
|
||||
in old commonly used C libraries.
|
||||
@@ -2099,13 +2099,13 @@ someVar=$(stripHash $name)
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In order to alleviate this burden, the <firstterm>setup
|
||||
hook></firstterm>mechanism was written, where any package can include a
|
||||
shell script that [by convention rather than enforcement by Nix], any
|
||||
downstream reverse-dependency will source as part of its build process. That
|
||||
allows the downstream dependency to merely specify its dependencies, and
|
||||
lets those dependencies effectively initialize themselves. No boilerplate
|
||||
mirroring the list of dependencies is needed.
|
||||
In order to alleviate this burden, the <firstterm>setup hook</firstterm>
|
||||
mechanism was written, where any package can include a shell script that [by
|
||||
convention rather than enforcement by Nix], any downstream
|
||||
reverse-dependency will source as part of its build process. That allows the
|
||||
downstream dependency to merely specify its dependencies, and lets those
|
||||
dependencies effectively initialize themselves. No boilerplate mirroring the
|
||||
list of dependencies is needed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@@ -2445,6 +2445,28 @@ addEnvHooks "$hostOffset" myBashFunction
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
breakpointHook
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This hook will make a build pause instead of stopping when a failure
|
||||
happen. It prevents nix to cleanup the build environment immediatly and
|
||||
allows the user to attach to a build environment using the
|
||||
<command>cntr</command> command. On build error it will print the
|
||||
instruction that are neccessary for <command>cntr</command>. Installing
|
||||
cntr and running the command will provide shell access to the build
|
||||
sandbox of failed build. At <filename>/var/lib/cntr</filename> the
|
||||
sandbox filesystem is mounted. All commands and files of the system are
|
||||
still accessible within the shell. To execute commands from the sandbox
|
||||
use the cntr exec subcommand. Note that <command>cntr</command> also
|
||||
needs to be executed on the machine that is doing the build, which might
|
||||
be not the case when remote builders are enabled.
|
||||
<command>cntr</command> is only supported on linux based platforms.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</para>
|
||||
</section>
|
||||
|
||||
Reference in New Issue
Block a user