diff options
author | Vladimír Čunát <vcunat@gmail.com> | 2016-01-25 10:02:15 +0100 |
---|---|---|
committer | Vladimír Čunát <vcunat@gmail.com> | 2016-01-25 10:02:25 +0100 |
commit | 2af19df36448dad74e5428987ef33135167b6ffa (patch) | |
tree | 86bc22dba9bcef4499859854f178e9fd3a656b12 /doc | |
parent | 9b980baa9db36aebf1396cafaa4dfc385d7b7009 (diff) | |
parent | 7362936cd6952b24a3ec14f2e961522691892fcf (diff) | |
download | nixlib-2af19df36448dad74e5428987ef33135167b6ffa.tar nixlib-2af19df36448dad74e5428987ef33135167b6ffa.tar.gz nixlib-2af19df36448dad74e5428987ef33135167b6ffa.tar.bz2 nixlib-2af19df36448dad74e5428987ef33135167b6ffa.tar.lz nixlib-2af19df36448dad74e5428987ef33135167b6ffa.tar.xz nixlib-2af19df36448dad74e5428987ef33135167b6ffa.tar.zst nixlib-2af19df36448dad74e5428987ef33135167b6ffa.zip |
Merge branch 'master' into staging
Diffstat (limited to 'doc')
-rw-r--r-- | doc/erlang-users-guide.xml | 17 | ||||
-rw-r--r-- | doc/stdenv.xml | 65 |
2 files changed, 82 insertions, 0 deletions
diff --git a/doc/erlang-users-guide.xml b/doc/erlang-users-guide.xml index 778d6e709b14..074ae50b1c05 100644 --- a/doc/erlang-users-guide.xml +++ b/doc/erlang-users-guide.xml @@ -3,6 +3,23 @@ xml:id="users-guide-to-the-erlang-infrastructure"> <title>User's Guide to the Erlang Infrastructure</title> +<section xml:id="build-tools"> + <title>Build Tools</title> + <para> + By default Rebar3 wants to manage it's own dependencies. In the + normal non-Nix, this is perfectly acceptable. In the Nix world it + is not. To support this we have created two versions of rebar3, + <literal>rebar3</literal> and <literal>rebar3-open</literal>. The + <literal>rebar3</literal> version has been patched to remove the + ability to download anything from it. If you are not running it a + nix-shell or a nix-build then its probably not going to work for + you. <literal>rebar3-open</literal> is the normal, un-modified + rebar3. It should work exactly as would any other version of + rebar3. Any Erlang package should rely on + <literal>rebar3</literal> and thats really what you should be + using too. + </para> +</section> <section xml:id="how-to-install-erlang-packages"> <title>How to install Erlang packages</title> diff --git a/doc/stdenv.xml b/doc/stdenv.xml index 6bb1002a4c67..f8d9acb2fb0c 100644 --- a/doc/stdenv.xml +++ b/doc/stdenv.xml @@ -224,6 +224,63 @@ genericBuild </variablelist> +<variablelist> + <title>Variables affecting build properties</title> + + <varlistentry> + <term><varname>enableParallelBuilding</varname></term> + <listitem><para>If set, <literal>stdenv</literal> will pass specific + flags to <literal>make</literal> and other build tools to enable + parallel building with up to <literal>build-cores</literal> + workers.</para></listitem> + </varlistentry> + + <varlistentry> + <term><varname>preferLocalBuild</varname></term> + <listitem><para>If set, specifies that the package is so lightweight + in terms of build operations (e.g. write a text file from a Nix string + to the store) that there's no need to look for it in binary caches -- + it's faster to just build it locally. It also tells Hydra and other + facilities that this package doesn't need to be exported in binary + caches (noone would use it, after all).</para></listitem> + </varlistentry> + +</variablelist> + +<variablelist> + <title>Special variables</title> + + <varlistentry> + <term><varname>passthru</varname></term> + <listitem><para>This is an attribute set which can be filled with arbitrary + values. For example: + +<programlisting> +passthru = { + foo = "bar"; + baz = { + value1 = 4; + value2 = 5; + }; +} +</programlisting> + +</para> + + <para>Values inside it are not passed to the builder, so you can change + them without triggering a rebuild. However, they can be accessed outside of a + derivation directly, as if they were set inside a derivation itself, e.g. + <literal>hello.baz.value1</literal>. We don't specify any usage or + schema of <literal>passthru</literal> - it is meant for values that would be + useful outside the derivation in other parts of a Nix expression (e.g. in other + derivations). An example would be to convey some specific dependency of your + derivation which contains a program with plugins support. Later, others who + make derivations with plugins can use passed-through dependency to ensure that + their plugin would be binary-compatible with built program.</para></listitem> + </varlistentry> + +</variablelist> + </section> @@ -1187,6 +1244,14 @@ echo @foo@ </varlistentry> <varlistentry> + <term>Autoconf</term> + <listitem><para>The <varname>autoreconfHook</varname> derivation adds + <varname>autoreconfPhase</varname>, which runs autoreconf, libtoolize and + automake, essentially preparing the configure script in autotools-based + builds.</para></listitem> + </varlistentry> + + <varlistentry> <term>libxml2</term> <listitem><para>Adds every file named <filename>catalog.xml</filename> found under the |