diff options
Diffstat (limited to 'doc/cross-compilation.xml')
| -rw-r--r-- | doc/cross-compilation.xml | 41 |
1 files changed, 40 insertions, 1 deletions
diff --git a/doc/cross-compilation.xml b/doc/cross-compilation.xml index 4b35b72feae0..118a82bf0b06 100644 --- a/doc/cross-compilation.xml +++ b/doc/cross-compilation.xml @@ -187,7 +187,7 @@ How does this work in practice? Nixpkgs is now structured so that build-time dependencies are taken from <varname>buildPackages</varname>, whereas run-time dependencies are taken from the top level attribute set. For example, <varname>buildPackages.gcc</varname> should be used at build time, while <varname>gcc</varname> should be used at run time. Now, for most of Nixpkgs's history, there was no <varname>buildPackages</varname>, and most packages have not been refactored to use it explicitly. - Instead, one can use the four attributes used for specifying dependencies as documented in <xref linkend="ssec-stdenv-attributes"/>. + Instead, one can use the six (<emphasis>gasp</emphasis>) attributes used for specifying dependencies as documented in <xref linkend="ssec-stdenv-dependencies"/>. We "splice" together the run-time and build-time package sets with <varname>callPackage</varname>, and then <varname>mkDerivation</varname> for each of four attributes pulls the right derivation out. This splicing can be skipped when not cross compiling as the package sets are the same, but is a bit slow for cross compiling. Because of this, a best-of-both-worlds solution is in the works with no splicing or explicit access of <varname>buildPackages</varname> needed. @@ -200,6 +200,45 @@ </para></note> </section> + <section> + <title>Cross packagaing cookbook</title> + <para> + Some frequently problems when packaging for cross compilation are good to just spell and answer. + Ideally the information above is exhaustive, so this section cannot provide any new information, + but its ludicrous and cruel to expect everyone to spend effort working through the interaction of many features just to figure out the same answer to the same common problem. + Feel free to add to this list! + </para> + <qandaset> + <qandaentry> + <question><para> + What if my package's build system needs to build a C program to be run under the build environment? + </para></question> + <answer><para> + <programlisting>depsBuildBuild = [ buildPackages.stdenv.cc ];</programlisting> + Add it to your <function>mkDerivation</function> invocation. + </para></answer> + </qandaentry> + <qandaentry> + <question><para> + My package fails to find <command>ar</command>. + </para></question> + <answer><para> + Many packages assume that an unprefixed <command>ar</command> is available, but Nix doesn't provide one. + It only provides a prefixed one, just as it only does for all the other binutils programs. + It may be necessary to patch the package to fix the build system to use a prefixed `ar`. + </para></answer> + </qandaentry> + <qandaentry> + <question><para> + My package's testsuite needs to run host platform code. + </para></question> + <answer><para> + <programlisting>doCheck = stdenv.hostPlatform != stdenv.buildPlatfrom;</programlisting> + Add it to your <function>mkDerivation</function> invocation. + </para></answer> + </qandaentry> + </qandaset> + </section> </section> <!--============================================================--> |