dev/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

nixpkgs doc: Talk about nativeBuildInputs and propgatedNativeBuildInputs

Browse Source 
Do so in the stdenv section where the other two are discussed. This can be
done without brining up cross-compilation by talking about build-time vs
run-time.
This commit is contained in:
John Ericson 2017-01-22 14:36:46 -05:00
parent 7dc4e43837
commit 76ea89aa78
1 changed files with 54 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
doc/stdenv.xml
View File

@ -194,34 +194,53 @@ genericBuild
tools.</para></listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Variables specifying dependencies</title>
<varlistentry>
<term><varname>nativeBuildInputs</varname></term>
<listitem><para>
A list of dependencies used by the new derivation at <emphasis>build</emphasis>-time.
I.e. these dependencies should not make it into the package's runtime-closure, though this is currently not checked.
For each dependency <replaceable>dir</replaceable>, the directory <filename><replaceable>dir</replaceable>/bin</filename>, if it exists, is added to the <envar>PATH</envar> environment variable.
Other environment variables are also set up via a pluggable mechanism.
For instance, if <varname>buildInputs</varname> contains Perl, then the <filename>lib/site_perl</filename> subdirectory of each input is added to the <envar>PERL5LIB</envar> environment variable.
See <xref linkend="ssec-setup-hooks"/> for details.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>buildInputs</varname></term>
<listitem><para>A list of dependencies used by
<literal>stdenv</literal> to set up the environment for the build.
For each dependency <replaceable>dir</replaceable>, the directory
<filename><replaceable>dir</replaceable>/bin</filename>, if it
exists, is added to the <envar>PATH</envar> environment variable.
Other environment variables are also set up via a pluggable
mechanism. For instance, if <varname>buildInputs</varname>
contains Perl, then the <filename>lib/site_perl</filename>
subdirectory of each input is added to the <envar>PERL5LIB</envar>
environment variable. See <xref linkend="ssec-setup-hooks"/> for
details.</para></listitem>
<listitem><para>
A list of dependencies used by the new derivation at <emphasis>run</emphasis>-time.
Currently, the build-time environment is modified in the exact same way as with <varname>nativeBuildInputs</varname>.
This is problematic in that when cross-compiling, foreign executables can clobber native ones on the <envar>PATH</envar>.
Even more confusing is static-linking.
A statically-linked library should be listed here because ultimately that generated machine code will be used at run-time, even though a derivation containing the object files or static archives will only be used at build-time.
A less confusing solution to this would be nice.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>propagatedNativeBuildInputs</varname></term>
<listitem><para>
Like <varname>nativeBuildInputs</varname>, but these dependencies are <emphasis>propagated</emphasis>:
that is, the dependencies listed here are added to the <varname>nativeBuildInputs</varname> of any package that uses <emphasis>this</emphasis> package as a dependency.
So if package Y has <literal>propagatedBuildInputs = [X]</literal>, and package Z has <literal>buildInputs = [Y]</literal>, then package X will appear in Z’s build environment automatically.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>propagatedBuildInputs</varname></term>
<listitem><para>Like <varname>buildInputs</varname>, but these
dependencies are <emphasis>propagated</emphasis>: that is, the
dependencies listed here are added to the
<varname>buildInputs</varname> of any package that uses
<emphasis>this</emphasis> package as a dependency. So if package
Y has <literal>propagatedBuildInputs = [X]</literal>, and package
Z has <literal>buildInputs = [Y]</literal>, then package X will
appear in Z’s build environment automatically.</para></listitem>
<listitem><para>
Like <varname>buildInputs</varname>, but propagated just like <varname>propagatedNativeBuildInputs</varname>.
This inherits <varname>buildInputs</varname>'s flaws of clobbering native executables when cross-compiling and being confusing for static linking.
</para></listitem>
</varlistentry>
</variablelist>
<variablelist>
@ -1607,4 +1626,3 @@ Arch Wiki</link>.
</section>
</chapter>