nixpkgs docs: give linked things IDs

+3 -3
doc/cross-compilation.xml
···
</para>
<qandaset>
-
<qandaentry>
<question>
<para>
What if my package's build system needs to build a C program to be run
···
</para>
</answer>
</qandaentry>
-
<qandaentry>
<question>
<para>
My package fails to find <command>ar</command>.
···
</para>
</answer>
</qandaentry>
-
<qandaentry>
<question>
<para>
My package's testsuite needs to run host platform code.
···
</para>
<qandaset>
+
<qandaentry xml:id="cross-qa-build-c-program-in-build-environment">
<question>
<para>
What if my package's build system needs to build a C program to be run
···
</para>
</answer>
</qandaentry>
+
<qandaentry xml:id="cross-qa-fails-to-find-ar">
<question>
<para>
My package fails to find <command>ar</command>.
···
</para>
</answer>
</qandaentry>
+
<qandaentry xml:id="cross-testsuite-runs-host-code">
<question>
<para>
My package's testsuite needs to run host platform code.
+5 -5
doc/multiple-output.xml
···
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="chap-multiple-output">
<title>Multiple-output packages</title>
-
<section>
<title>Introduction</title>
<para>
···
</para>
</note>
</section>
-
<section>
<title>Installing a split package</title>
<para>
···
</listitem>
</itemizedlist>
</section>
-
<section>
<title>Using a split package</title>
<para>
···
also added. (See <xref linkend="multiple-output-file-type-groups" />.)
</para>
</section>
-
<section>
<title>Writing a split derivation</title>
<para>
···
</variablelist>
</section>
-
<section>
<title>Common caveats</title>
<itemizedlist>
···
xmlns:xlink="http://www.w3.org/1999/xlink"
xml:id="chap-multiple-output">
<title>Multiple-output packages</title>
+
<section xml:id="sec-multiple-outputs-introduction">
<title>Introduction</title>
<para>
···
</para>
</note>
</section>
+
<section xml:id="sec-multiple-outputs-installing">
<title>Installing a split package</title>
<para>
···
</listitem>
</itemizedlist>
</section>
+
<section xml:id="sec-multiple-outputs-using-split-packages">
<title>Using a split package</title>
<para>
···
also added. (See <xref linkend="multiple-output-file-type-groups" />.)
</para>
</section>
+
<section xml:id="sec-multiple-outputs-">
<title>Writing a split derivation</title>
<para>
···
</variablelist>
</section>
+
<section xml:id="sec-multiple-outputs-caveats">
<title>Common caveats</title>
<itemizedlist>
+2 -2
doc/package-notes.xml
···
</section>
<!--============================================================-->
<!--
-
<section>
<title>Gnome</title>
<para>* Expression is auto-generated</para>
<para>* How to update</para>
···
-->
<!--============================================================-->
<!--
-
<section>
<title>GCC</title>
<para>…</para>
</section>
···
</section>
<!--============================================================-->
<!--
+
<section xml:id="sec-package-notes-gnome">
<title>Gnome</title>
<para>* Expression is auto-generated</para>
<para>* How to update</para>
···
-->
<!--============================================================-->
<!--
+
<section xml:id="sec-package-notes-gcc">
<title>GCC</title>
<para>…</para>
</section>
+8 -8
doc/release-notes.xml
···
<article xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Nixpkgs Release Notes</title>
-
<section>
<title>Release 0.14 (June 4, 2012)</title>
<para>
···
packages by numerous contributors. For details, see the commit logs.
</para>
</section>
-
<section>
<title>Release 0.13 (February 5, 2010)</title>
<para>
···
</itemizedlist>
</para>
</section>
-
<section>
<title>Release 0.12 (April 24, 2009)</title>
<para>
···
<literal>nix-dev</literal> mailing list.
</para>
</section>
-
<section>
<title>Release 0.11 (September 11, 2007)</title>
<para>
···
Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov.
</para>
</section>
-
<section>
<title>Release 0.10 (October 12, 2006)</title>
<note>
···
Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
</para>
</section>
-
<section>
<title>Release 0.9 (January 31, 2006)</title>
<para>
···
Martin Bravenboer, Rob Vermaas and Roy van den Broek.
</para>
</section>
-
<section>
<title>Release 0.8 (April 11, 2005)</title>
<para>
···
</itemizedlist>
</para>
</section>
-
<section>
<title>Release 0.7 (March 14, 2005)</title>
<itemizedlist>
···
<article xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Nixpkgs Release Notes</title>
+
<section xml:id="release-notes-0.14">
<title>Release 0.14 (June 4, 2012)</title>
<para>
···
packages by numerous contributors. For details, see the commit logs.
</para>
</section>
+
<section xml:id="release-notes-0.13">
<title>Release 0.13 (February 5, 2010)</title>
<para>
···
</itemizedlist>
</para>
</section>
+
<section xml:id="release-notes-0.12">
<title>Release 0.12 (April 24, 2009)</title>
<para>
···
<literal>nix-dev</literal> mailing list.
</para>
</section>
+
<section xml:id="release-notes-0.11">
<title>Release 0.11 (September 11, 2007)</title>
<para>
···
Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov.
</para>
</section>
+
<section xml:id="release-notes-0.10">
<title>Release 0.10 (October 12, 2006)</title>
<note>
···
Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
</para>
</section>
+
<section xml:id="release-notes-0.9">
<title>Release 0.9 (January 31, 2006)</title>
<para>
···
Martin Bravenboer, Rob Vermaas and Roy van den Broek.
</para>
</section>
+
<section xml:id="release-notes-0.8">
<title>Release 0.8 (April 11, 2005)</title>
<para>
···
</itemizedlist>
</para>
</section>
+
<section xml:id="release-notes-0.7">
<title>Release 0.7 (March 14, 2005)</title>
<itemizedlist>
+4 -4
doc/reviewing-contributions.xml
···
</listitem>
</itemizedlist>
-
<example>
<title>Sample template for a package update review</title>
<screen>
##### Reviewed points
···
</listitem>
</itemizedlist>
-
<example>
<title>Sample template for a new package review</title>
<screen>
##### Reviewed points
···
</listitem>
</itemizedlist>
-
<example>
<title>Sample template for a module update review</title>
<screen>
##### Reviewed points
···
</listitem>
</itemizedlist>
-
<example>
<title>Sample template for a new module review</title>
<screen>
##### Reviewed points
···
</listitem>
</itemizedlist>
+
<example xml:id="reviewing-contributions-sample-package-update">
<title>Sample template for a package update review</title>
<screen>
##### Reviewed points
···
</listitem>
</itemizedlist>
+
<example xml:id="reviewing-contributions-sample-new-package">
<title>Sample template for a new package review</title>
<screen>
##### Reviewed points
···
</listitem>
</itemizedlist>
+
<example xml:id="reviewing-contributions-sample-module-update">
<title>Sample template for a module update review</title>
<screen>
##### Reviewed points
···
</listitem>
</itemizedlist>
+
<example xml:id="reviewing-contributions-sample-new-module">
<title>Sample template for a new module review</title>
<screen>
##### Reviewed points
+7 -7
doc/stdenv.xml
···
platforms relative to the new derivation's, and whether they are propagated.
The platform distinctions are motivated by cross compilation; see
<xref linkend="chap-cross"/> for exactly what each platform means.
-
<footnote>
<para>
The build platform is ignored because it is a mere implementation detail
of the package satisfying the dependency: As a general programming
···
out only for dependencies whose host platform matches the new derivation's
build platform–i.e. which run on the platform where the new derivation
will be built.
-
<footnote>
<para>
Currently, that means for native builds all dependencies are put on the
<envar>PATH</envar>. But in the future that may not be the case for sake
···
<link xlink:href="https://en.wikipedia.org/wiki/Natural_deduction">Natural
Deduction</link> using the inference rules. This probably seems a bit
obtuse, but so is the bash code that actually implements it!
-
<footnote>
<para>
The <function>findInputs</function> function, currently residing in
<filename>pkgs/stdenv/generic/setup.sh</filename>, implements the
···
By default, the configure phase applies some special hackery to all
files called <filename>ltmain.sh</filename> before running the configure
script in order to improve the purity of Libtool-based packages
-
<footnote>
<para>
It clears the
<varname>sys_lib_<replaceable>*</replaceable>search_path</varname>
···
or a subset to control exactly which platform flags are passed.
Compilers and other tools should use this to also pass the target
platform, for example.
-
<footnote>
<para>
Eventually these will be passed when in native builds too, to improve
determinism: build-time guessing, as is done today, is a risk of
···
Controls whether the installCheck phase is executed. By default it is
skipped, but if <varname>doInstallCheck</varname> is set to true, the
installCheck phase is usually executed. Thus you should set
-
<programlisting>doInstallCheck = true;</programlisting>
in the derivation to enable install checks. The exception is cross
compilation. Cross compiled builds never run tests, no matter how
<varname>doInstallCheck</varname> is set, as the newly-built program
···
<command>clang</command> is to be used. Secondly, this helps packages
not get confused when cross-compiling, in which case multiple Bintools
Wrappers may simultaneously be in use.
-
<footnote>
<para>
Each wrapper targets a single platform, so if binaries for multiple
platforms are needed, the underlying binaries must be wrapped multiple
···
platforms relative to the new derivation's, and whether they are propagated.
The platform distinctions are motivated by cross compilation; see
<xref linkend="chap-cross"/> for exactly what each platform means.
+
<footnote xml:id="footnote-stdenv-ignored-build-platform">
<para>
The build platform is ignored because it is a mere implementation detail
of the package satisfying the dependency: As a general programming
···
out only for dependencies whose host platform matches the new derivation's
build platform–i.e. which run on the platform where the new derivation
will be built.
+
<footnote xml:id="footnote-stdenv-native-dependencies-in-path">
<para>
Currently, that means for native builds all dependencies are put on the
<envar>PATH</envar>. But in the future that may not be the case for sake
···
<link xlink:href="https://en.wikipedia.org/wiki/Natural_deduction">Natural
Deduction</link> using the inference rules. This probably seems a bit
obtuse, but so is the bash code that actually implements it!
+
<footnote xml:id="footnote-stdenv-find-inputs-location">
<para>
The <function>findInputs</function> function, currently residing in
<filename>pkgs/stdenv/generic/setup.sh</filename>, implements the
···
By default, the configure phase applies some special hackery to all
files called <filename>ltmain.sh</filename> before running the configure
script in order to improve the purity of Libtool-based packages
+
<footnote xml:id="footnote-stdenv-sys-lib-search-path">
<para>
It clears the
<varname>sys_lib_<replaceable>*</replaceable>search_path</varname>
···
or a subset to control exactly which platform flags are passed.
Compilers and other tools should use this to also pass the target
platform, for example.
+
<footnote xml:id="footnote-stdenv-build-time-guessing-impurity">
<para>
Eventually these will be passed when in native builds too, to improve
determinism: build-time guessing, as is done today, is a risk of
···
Controls whether the installCheck phase is executed. By default it is
skipped, but if <varname>doInstallCheck</varname> is set to true, the
installCheck phase is usually executed. Thus you should set
+
<programlisting>doInstallCheck = true;</programlisting>
in the derivation to enable install checks. The exception is cross
compilation. Cross compiled builds never run tests, no matter how
<varname>doInstallCheck</varname> is set, as the newly-built program
···
<command>clang</command> is to be used. Secondly, this helps packages
not get confused when cross-compiling, in which case multiple Bintools
Wrappers may simultaneously be in use.
+
<footnote xml:id="footnote-stdenv-per-platform-wrapper">
<para>
Each wrapper targets a single platform, so if binaries for multiple
platforms are needed, the underlying binaries must be wrapped multiple