Merge master into staging-next

This commit is contained in:
Frederik Rietdijk
2018-10-27 09:04:53 +02:00
205 changed files with 3215 additions and 2188 deletions

View File

@@ -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>

View File

@@ -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
};

View File

@@ -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>