2016-04-27 13:29:33 +01:00
|
|
|
|
{ pkgs, options, config, version, revision, extraSources ? [] }:
|
2008-06-05 16:33:17 +01:00
|
|
|
|
|
2014-08-09 15:30:44 +01:00
|
|
|
|
with pkgs;
|
2013-10-17 13:09:05 +01:00
|
|
|
|
|
2011-09-14 19:20:50 +01:00
|
|
|
|
let
|
2016-07-28 03:27:39 +01:00
|
|
|
|
lib = pkgs.lib;
|
2009-10-06 00:15:06 +01:00
|
|
|
|
|
2013-10-23 18:32:19 +01:00
|
|
|
|
# Remove invisible and internal options.
|
2016-04-20 22:46:02 +01:00
|
|
|
|
optionsListVisible = lib.filter (opt: opt.visible && !opt.internal) (lib.optionAttrSetToDocList options);
|
2014-08-27 10:53:08 +01:00
|
|
|
|
|
|
|
|
|
# Replace functions by the string <function>
|
|
|
|
|
substFunction = x:
|
2016-07-28 03:27:39 +01:00
|
|
|
|
if builtins.isAttrs x then lib.mapAttrs (name: substFunction) x
|
2014-08-27 10:53:08 +01:00
|
|
|
|
else if builtins.isList x then map substFunction x
|
2018-01-31 19:02:19 +00:00
|
|
|
|
else if lib.isFunction x then "<function>"
|
2014-08-27 10:53:08 +01:00
|
|
|
|
else x;
|
2013-10-23 18:32:19 +01:00
|
|
|
|
|
2016-04-20 22:57:33 +01:00
|
|
|
|
# Generate DocBook documentation for a list of packages. This is
|
|
|
|
|
# what `relatedPackages` option of `mkOption` from
|
|
|
|
|
# ../../../lib/options.nix influences.
|
|
|
|
|
#
|
|
|
|
|
# Each element of `relatedPackages` can be either
|
|
|
|
|
# - a string: that will be interpreted as an attribute name from `pkgs`,
|
|
|
|
|
# - a list: that will be interpreted as an attribute path from `pkgs`,
|
|
|
|
|
# - an attrset: that can specify `name`, `path`, `package`, `comment`
|
|
|
|
|
# (either of `name`, `path` is required, the rest are optional).
|
|
|
|
|
genRelatedPackages = packages:
|
|
|
|
|
let
|
|
|
|
|
unpack = p: if lib.isString p then { name = p; }
|
|
|
|
|
else if lib.isList p then { path = p; }
|
|
|
|
|
else p;
|
|
|
|
|
describe = args:
|
|
|
|
|
let
|
2018-04-25 07:26:13 +01:00
|
|
|
|
title = args.title or null;
|
2016-04-20 22:57:33 +01:00
|
|
|
|
name = args.name or (lib.concatStringsSep "." args.path);
|
|
|
|
|
path = args.path or [ args.name ];
|
|
|
|
|
package = args.package or (lib.attrByPath path (throw "Invalid package attribute path `${toString path}'") pkgs);
|
|
|
|
|
in "<listitem>"
|
2018-04-25 07:26:13 +01:00
|
|
|
|
+ "<para><literal>${lib.optionalString (title != null) "${title} aka "}pkgs.${name} (${package.meta.name})</literal>"
|
2018-02-17 18:44:23 +00:00
|
|
|
|
+ lib.optionalString (!package.meta.available) " <emphasis>[UNAVAILABLE]</emphasis>"
|
2016-04-20 22:57:33 +01:00
|
|
|
|
+ ": ${package.meta.description or "???"}.</para>"
|
|
|
|
|
+ lib.optionalString (args ? comment) "\n<para>${args.comment}</para>"
|
|
|
|
|
# Lots of `longDescription's break DocBook, so we just wrap them into <programlisting>
|
|
|
|
|
+ lib.optionalString (package.meta ? longDescription) "\n<programlisting>${package.meta.longDescription}</programlisting>"
|
|
|
|
|
+ "</listitem>";
|
|
|
|
|
in "<itemizedlist>${lib.concatStringsSep "\n" (map (p: describe (unpack p)) packages)}</itemizedlist>";
|
|
|
|
|
|
2016-04-20 22:46:02 +01:00
|
|
|
|
optionsListDesc = lib.flip map optionsListVisible (opt: opt // {
|
2016-04-20 22:57:33 +01:00
|
|
|
|
# Clean up declaration sites to not refer to the NixOS source tree.
|
2016-01-29 15:20:22 +00:00
|
|
|
|
declarations = map stripAnyPrefixes opt.declarations;
|
2014-08-27 10:53:08 +01:00
|
|
|
|
}
|
2016-07-28 03:27:39 +01:00
|
|
|
|
// lib.optionalAttrs (opt ? example) { example = substFunction opt.example; }
|
|
|
|
|
// lib.optionalAttrs (opt ? default) { default = substFunction opt.default; }
|
2016-04-20 22:57:33 +01:00
|
|
|
|
// lib.optionalAttrs (opt ? type) { type = substFunction opt.type; }
|
2018-04-25 07:26:13 +01:00
|
|
|
|
// lib.optionalAttrs (opt ? relatedPackages && opt.relatedPackages != []) { relatedPackages = genRelatedPackages opt.relatedPackages; });
|
2013-10-23 18:32:19 +01:00
|
|
|
|
|
2016-01-22 19:22:12 +00:00
|
|
|
|
# We need to strip references to /nix/store/* from options,
|
|
|
|
|
# including any `extraSources` if some modules came from elsewhere,
|
|
|
|
|
# or else the build will fail.
|
|
|
|
|
#
|
|
|
|
|
# E.g. if some `options` came from modules in ${pkgs.customModules}/nix,
|
2016-01-29 15:20:22 +00:00
|
|
|
|
# you'd need to include `extraSources = [ pkgs.customModules ]`
|
2016-01-29 18:34:00 +00:00
|
|
|
|
prefixesToStrip = map (p: "${toString p}/") ([ ../../.. ] ++ extraSources);
|
2016-07-28 03:27:39 +01:00
|
|
|
|
stripAnyPrefixes = lib.flip (lib.fold lib.removePrefix) prefixesToStrip;
|
2013-10-23 18:32:19 +01:00
|
|
|
|
|
2016-04-20 22:46:02 +01:00
|
|
|
|
# Custom "less" that pushes up all the things ending in ".enable*"
|
2018-02-11 22:41:06 +00:00
|
|
|
|
# and ".package*"
|
|
|
|
|
optionLess = a: b:
|
2016-04-20 22:46:02 +01:00
|
|
|
|
let
|
|
|
|
|
ise = lib.hasPrefix "enable";
|
|
|
|
|
isp = lib.hasPrefix "package";
|
|
|
|
|
cmp = lib.splitByAndCompare ise lib.compare
|
|
|
|
|
(lib.splitByAndCompare isp lib.compare lib.compare);
|
2018-02-11 22:06:50 +00:00
|
|
|
|
in lib.compareLists cmp a.loc b.loc < 0;
|
2016-04-20 22:46:02 +01:00
|
|
|
|
|
|
|
|
|
# Customly sort option list for the man page.
|
2018-02-11 22:41:06 +00:00
|
|
|
|
optionsList = lib.sort optionLess optionsListDesc;
|
2016-04-20 22:46:02 +01:00
|
|
|
|
|
2015-09-24 10:47:00 +01:00
|
|
|
|
# Convert the list of options into an XML file.
|
2016-04-20 22:46:02 +01:00
|
|
|
|
optionsXML = builtins.toFile "options.xml" (builtins.toXML optionsList);
|
2008-01-04 14:24:42 +00:00
|
|
|
|
|
2014-08-09 15:30:44 +01:00
|
|
|
|
optionsDocBook = runCommand "options-db.xml" {} ''
|
2014-11-17 12:41:18 +00:00
|
|
|
|
optionsXML=${optionsXML}
|
2014-08-27 10:53:08 +01:00
|
|
|
|
if grep /nixpkgs/nixos/modules $optionsXML; then
|
2013-10-23 19:06:17 +01:00
|
|
|
|
echo "The manual appears to depend on the location of Nixpkgs, which is bad"
|
|
|
|
|
echo "since this prevents sharing via the NixOS channel. This is typically"
|
|
|
|
|
echo "caused by an option default that refers to a relative path (see above"
|
|
|
|
|
echo "for hints about the offending path)."
|
|
|
|
|
exit 1
|
|
|
|
|
fi
|
2018-03-01 15:37:57 +00:00
|
|
|
|
${buildPackages.libxslt.bin}/bin/xsltproc \
|
2009-10-06 00:47:50 +01:00
|
|
|
|
--stringparam revision '${revision}' \
|
nixos: Split paras by \n\n in option descriptions
What annoyed me for a long time was the fact, that in order to break
into a new paragraph, you need to insert </para><para> in the
description attribute of an option.
Now we will automatically create <para/> elements for every block that
is separated by two consecutive newlines.
I first tried to do this within options-to-docbook.xsl, but it turns
out[1] that this isn't directly possible with XSLT 1.0, so I added
another XSLT file that postprocesses the option descriptions that are
now enclosed in <nixos:option-description/> by options-to-docbook.xsl.
The splitting itself is a bit more involved, because we can't simply
split on every \n\n because we'd also split text nodes of elements, for
example:
<screen><![CDATA[
one line
another one
]]></screen>
This would create one <para/> element for "one line" and another for
"another line", which we obviously don't want because <screen/> is used
to display verbatim contents of what a user is seeing on the screen.
So what we do instead is splitting *only* the top-level text nodes
within the outermost <para/> and leave all elements as-is. If there are
more than one <para/> elements at the top-level, we simply don't process
it at all, because the description then already contains </para><para>.
https://www.mhonarc.org/archive/html/xsl-list/2012-09/msg00319.html
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra, @domenkozar
2018-09-02 04:05:34 +01:00
|
|
|
|
-o intermediate.xml ${./options-to-docbook.xsl} $optionsXML
|
|
|
|
|
${buildPackages.libxslt.bin}/bin/xsltproc \
|
|
|
|
|
-o "$out" ${./postprocess-option-descriptions.xsl} intermediate.xml
|
2008-01-04 14:24:42 +00:00
|
|
|
|
'';
|
2009-09-18 16:10:37 +01:00
|
|
|
|
|
2016-07-28 03:27:39 +01:00
|
|
|
|
sources = lib.sourceFilesBySuffices ./. [".xml"];
|
2014-08-25 13:33:17 +01:00
|
|
|
|
|
2016-04-27 13:29:33 +01:00
|
|
|
|
modulesDoc = builtins.toFile "modules.xml" ''
|
|
|
|
|
<section xmlns:xi="http://www.w3.org/2001/XInclude" id="modules">
|
|
|
|
|
${(lib.concatMapStrings (path: ''
|
|
|
|
|
<xi:include href="${path}" />
|
|
|
|
|
'') (lib.catAttrs "value" config.meta.doc))}
|
|
|
|
|
</section>
|
|
|
|
|
'';
|
|
|
|
|
|
2018-04-28 03:44:25 +01:00
|
|
|
|
generatedSources = runCommand "generated-docbook" {} ''
|
|
|
|
|
mkdir $out
|
|
|
|
|
ln -s ${modulesDoc} $out/modules.xml
|
|
|
|
|
ln -s ${optionsDocBook} $out/options-db.xml
|
|
|
|
|
printf "%s" "${version}" > $out/version
|
|
|
|
|
'';
|
|
|
|
|
|
2014-08-25 13:33:17 +01:00
|
|
|
|
copySources =
|
|
|
|
|
''
|
|
|
|
|
cp -prd $sources/* . # */
|
2018-04-28 03:44:25 +01:00
|
|
|
|
ln -s ${generatedSources} ./generated
|
2014-08-27 11:24:10 +01:00
|
|
|
|
chmod -R u+w .
|
2014-08-25 13:33:17 +01:00
|
|
|
|
'';
|
|
|
|
|
|
2015-07-22 15:09:00 +01:00
|
|
|
|
toc = builtins.toFile "toc.xml"
|
|
|
|
|
''
|
|
|
|
|
<toc role="chunk-toc">
|
|
|
|
|
<d:tocentry xmlns:d="http://docbook.org/ns/docbook" linkend="book-nixos-manual"><?dbhtml filename="index.html"?>
|
2015-07-22 15:17:06 +01:00
|
|
|
|
<d:tocentry linkend="ch-options"><?dbhtml filename="options.html"?></d:tocentry>
|
|
|
|
|
<d:tocentry linkend="ch-release-notes"><?dbhtml filename="release-notes.html"?></d:tocentry>
|
2015-07-22 15:09:00 +01:00
|
|
|
|
</d:tocentry>
|
|
|
|
|
</toc>
|
|
|
|
|
'';
|
|
|
|
|
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
manualXsltprocOptions = toString [
|
|
|
|
|
"--param section.autolabel 1"
|
|
|
|
|
"--param section.label.includes.component.label 1"
|
2018-04-05 12:54:01 +01:00
|
|
|
|
"--stringparam html.stylesheet 'style.css overrides.css highlightjs/mono-blue.css'"
|
|
|
|
|
"--stringparam html.script './highlightjs/highlight.pack.js ./highlightjs/loader.js'"
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
"--param xref.with.number.and.title 1"
|
|
|
|
|
"--param toc.section.depth 3"
|
|
|
|
|
"--stringparam admon.style ''"
|
2018-04-05 12:54:01 +01:00
|
|
|
|
"--stringparam callout.graphics.extension .svg"
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
"--stringparam current.docid manual"
|
|
|
|
|
"--param chunk.section.depth 0"
|
|
|
|
|
"--param chunk.first.sections 1"
|
|
|
|
|
"--param use.id.as.filename 1"
|
|
|
|
|
"--stringparam generate.toc 'book toc appendix toc'"
|
|
|
|
|
"--stringparam chunk.toc ${toc}"
|
|
|
|
|
];
|
|
|
|
|
|
2017-06-28 18:02:33 +01:00
|
|
|
|
manual-combined = runCommand "nixos-manual-combined"
|
2016-09-27 14:26:37 +01:00
|
|
|
|
{ inherit sources;
|
2018-03-21 19:02:15 +00:00
|
|
|
|
nativeBuildInputs = [ buildPackages.libxml2.bin buildPackages.libxslt.bin ];
|
2017-06-28 18:02:33 +01:00
|
|
|
|
meta.description = "The NixOS manual as plain docbook XML";
|
2016-09-27 14:26:37 +01:00
|
|
|
|
}
|
|
|
|
|
''
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
${copySources}
|
|
|
|
|
|
2017-06-28 18:02:33 +01:00
|
|
|
|
xmllint --xinclude --output ./manual-combined.xml ./manual.xml
|
|
|
|
|
xmllint --xinclude --noxincludenode \
|
|
|
|
|
--output ./man-pages-combined.xml ./man-pages.xml
|
|
|
|
|
|
2017-11-18 23:44:17 +00:00
|
|
|
|
# outputs the context of an xmllint error output
|
|
|
|
|
# LEN lines around the failing line are printed
|
|
|
|
|
function context {
|
|
|
|
|
# length of context
|
|
|
|
|
local LEN=6
|
|
|
|
|
# lines to print before error line
|
|
|
|
|
local BEFORE=4
|
|
|
|
|
|
|
|
|
|
# xmllint output lines are:
|
|
|
|
|
# file.xml:1234: there was an error on line 1234
|
|
|
|
|
while IFS=':' read -r file line rest; do
|
|
|
|
|
echo
|
|
|
|
|
if [[ -n "$rest" ]]; then
|
|
|
|
|
echo "$file:$line:$rest"
|
|
|
|
|
local FROM=$(($line>$BEFORE ? $line - $BEFORE : 1))
|
|
|
|
|
# number lines & filter context
|
|
|
|
|
nl --body-numbering=a "$file" | sed -n "$FROM,+$LEN p"
|
|
|
|
|
else
|
|
|
|
|
if [[ -n "$line" ]]; then
|
|
|
|
|
echo "$file:$line"
|
|
|
|
|
else
|
|
|
|
|
echo "$file"
|
|
|
|
|
fi
|
|
|
|
|
fi
|
|
|
|
|
done
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
function lintrng {
|
|
|
|
|
xmllint --debug --noout --nonet \
|
|
|
|
|
--relaxng ${docbook5}/xml/rng/docbook/docbook.rng \
|
|
|
|
|
"$1" \
|
|
|
|
|
2>&1 | context 1>&2
|
|
|
|
|
# ^ redirect assumes xmllint doesn’t print to stdout
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lintrng manual-combined.xml
|
|
|
|
|
lintrng man-pages-combined.xml
|
2017-06-28 18:02:33 +01:00
|
|
|
|
|
|
|
|
|
mkdir $out
|
|
|
|
|
cp manual-combined.xml $out/
|
|
|
|
|
cp man-pages-combined.xml $out/
|
|
|
|
|
'';
|
|
|
|
|
|
|
|
|
|
olinkDB = runCommand "manual-olinkdb"
|
|
|
|
|
{ inherit sources;
|
2018-03-21 19:02:15 +00:00
|
|
|
|
nativeBuildInputs = [ buildPackages.libxml2.bin buildPackages.libxslt.bin ];
|
2017-06-28 18:02:33 +01:00
|
|
|
|
}
|
|
|
|
|
''
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
xsltproc \
|
|
|
|
|
${manualXsltprocOptions} \
|
|
|
|
|
--stringparam collect.xref.targets only \
|
|
|
|
|
--stringparam targets.filename "$out/manual.db" \
|
2017-06-28 18:02:33 +01:00
|
|
|
|
--nonet \
|
2018-07-17 21:11:16 +01:00
|
|
|
|
${docbook_xsl_ns}/xml/xsl/docbook/xhtml/chunktoc.xsl \
|
2017-06-28 18:02:33 +01:00
|
|
|
|
${manual-combined}/manual-combined.xml
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
|
|
|
|
|
cat > "$out/olinkdb.xml" <<EOF
|
|
|
|
|
<?xml version="1.0" encoding="utf-8"?>
|
|
|
|
|
<!DOCTYPE targetset SYSTEM
|
2018-07-17 21:11:16 +01:00
|
|
|
|
"file://${docbook_xsl_ns}/xml/xsl/docbook/common/targetdatabase.dtd" [
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
<!ENTITY manualtargets SYSTEM "file://$out/manual.db">
|
|
|
|
|
]>
|
|
|
|
|
<targetset>
|
|
|
|
|
<targetsetinfo>
|
|
|
|
|
Allows for cross-referencing olinks between the manpages
|
2016-07-28 17:32:56 +01:00
|
|
|
|
and manual.
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
</targetsetinfo>
|
|
|
|
|
|
|
|
|
|
<document targetdoc="manual">&manualtargets;</document>
|
|
|
|
|
</targetset>
|
|
|
|
|
EOF
|
|
|
|
|
'';
|
|
|
|
|
|
2010-08-11 13:28:53 +01:00
|
|
|
|
in rec {
|
2018-04-28 09:00:55 +01:00
|
|
|
|
inherit generatedSources;
|
2010-08-11 13:28:53 +01:00
|
|
|
|
|
2014-11-17 12:41:18 +00:00
|
|
|
|
# The NixOS options in JSON format.
|
2016-09-27 14:26:37 +01:00
|
|
|
|
optionsJSON = runCommand "options-json"
|
|
|
|
|
{ meta.description = "List of NixOS options in JSON format";
|
|
|
|
|
}
|
|
|
|
|
''
|
2014-11-17 12:41:18 +00:00
|
|
|
|
# Export list of options in different format.
|
|
|
|
|
dst=$out/share/doc/nixos
|
|
|
|
|
mkdir -p $dst
|
|
|
|
|
|
2014-11-17 12:44:52 +00:00
|
|
|
|
cp ${builtins.toFile "options.json" (builtins.unsafeDiscardStringContext (builtins.toJSON
|
2016-04-20 22:46:02 +01:00
|
|
|
|
(builtins.listToAttrs (map (o: { name = o.name; value = removeAttrs o ["name" "visible" "internal"]; }) optionsList))))
|
2014-11-17 12:44:52 +00:00
|
|
|
|
} $dst/options.json
|
2014-11-17 12:41:18 +00:00
|
|
|
|
|
|
|
|
|
mkdir -p $out/nix-support
|
|
|
|
|
echo "file json $dst/options.json" >> $out/nix-support/hydra-build-products
|
|
|
|
|
''; # */
|
|
|
|
|
|
2010-08-11 13:28:53 +01:00
|
|
|
|
# Generate the NixOS manual.
|
2016-09-27 14:26:37 +01:00
|
|
|
|
manual = runCommand "nixos-manual"
|
|
|
|
|
{ inherit sources;
|
2018-03-21 19:02:15 +00:00
|
|
|
|
nativeBuildInputs = [ buildPackages.libxml2.bin buildPackages.libxslt.bin ];
|
2016-09-27 14:26:37 +01:00
|
|
|
|
meta.description = "The NixOS manual in HTML format";
|
|
|
|
|
allowedReferences = ["out"];
|
|
|
|
|
}
|
|
|
|
|
''
|
2009-10-05 14:17:45 +01:00
|
|
|
|
# Generate the HTML manual.
|
2009-07-14 16:47:03 +01:00
|
|
|
|
dst=$out/share/doc/nixos
|
2014-06-30 13:56:10 +01:00
|
|
|
|
mkdir -p $dst
|
2014-08-25 18:08:12 +01:00
|
|
|
|
xsltproc \
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
${manualXsltprocOptions} \
|
|
|
|
|
--stringparam target.database.document "${olinkDB}/olinkdb.xml" \
|
2017-06-28 18:02:33 +01:00
|
|
|
|
--nonet --output $dst/ \
|
2018-07-17 21:11:16 +01:00
|
|
|
|
${docbook_xsl_ns}/xml/xsl/docbook/xhtml/chunktoc.xsl \
|
2017-06-28 18:02:33 +01:00
|
|
|
|
${manual-combined}/manual-combined.xml
|
2009-09-18 16:10:37 +01:00
|
|
|
|
|
2012-07-25 16:54:24 +01:00
|
|
|
|
mkdir -p $dst/images/callouts
|
2018-07-17 21:11:16 +01:00
|
|
|
|
cp ${docbook_xsl_ns}/xml/xsl/docbook/images/callouts/*.svg $dst/images/callouts/
|
2013-01-09 12:43:57 +00:00
|
|
|
|
|
2018-04-05 12:54:01 +01:00
|
|
|
|
cp ${../../../doc/style.css} $dst/style.css
|
|
|
|
|
cp ${../../../doc/overrides.css} $dst/overrides.css
|
|
|
|
|
cp -r ${pkgs.documentation-highlighter} $dst/highlightjs
|
2011-09-14 19:20:50 +01:00
|
|
|
|
|
2013-10-24 19:06:02 +01:00
|
|
|
|
mkdir -p $out/nix-support
|
|
|
|
|
echo "nix-build out $out" >> $out/nix-support/hydra-build-products
|
2014-09-10 14:03:49 +01:00
|
|
|
|
echo "doc manual $dst" >> $out/nix-support/hydra-build-products
|
2012-07-25 16:54:24 +01:00
|
|
|
|
''; # */
|
2013-10-24 19:06:02 +01:00
|
|
|
|
|
2010-08-11 13:28:53 +01:00
|
|
|
|
|
2016-09-27 14:26:37 +01:00
|
|
|
|
manualEpub = runCommand "nixos-manual-epub"
|
|
|
|
|
{ inherit sources;
|
2018-03-21 19:02:15 +00:00
|
|
|
|
buildInputs = [ libxml2.bin libxslt.bin zip ];
|
2016-09-27 14:26:37 +01:00
|
|
|
|
}
|
|
|
|
|
''
|
2016-07-28 03:27:39 +01:00
|
|
|
|
# Generate the epub manual.
|
|
|
|
|
dst=$out/share/doc/nixos
|
|
|
|
|
|
|
|
|
|
xsltproc \
|
|
|
|
|
${manualXsltprocOptions} \
|
|
|
|
|
--stringparam target.database.document "${olinkDB}/olinkdb.xml" \
|
|
|
|
|
--nonet --xinclude --output $dst/epub/ \
|
2018-07-17 21:11:16 +01:00
|
|
|
|
${docbook_xsl_ns}/xml/xsl/docbook/epub/docbook.xsl \
|
2017-06-28 18:02:33 +01:00
|
|
|
|
${manual-combined}/manual-combined.xml
|
2016-07-28 03:27:39 +01:00
|
|
|
|
|
|
|
|
|
mkdir -p $dst/epub/OEBPS/images/callouts
|
2018-07-17 21:11:16 +01:00
|
|
|
|
cp -r ${docbook_xsl_ns}/xml/xsl/docbook/images/callouts/*.svg $dst/epub/OEBPS/images/callouts # */
|
2016-07-28 03:27:39 +01:00
|
|
|
|
echo "application/epub+zip" > mimetype
|
2016-08-01 10:02:41 +01:00
|
|
|
|
manual="$dst/nixos-manual.epub"
|
|
|
|
|
zip -0Xq "$manual" mimetype
|
|
|
|
|
cd $dst/epub && zip -Xr9D "$manual" *
|
|
|
|
|
|
|
|
|
|
rm -rf $dst/epub
|
2016-07-28 03:27:39 +01:00
|
|
|
|
|
|
|
|
|
mkdir -p $out/nix-support
|
2016-08-01 10:02:41 +01:00
|
|
|
|
echo "doc-epub manual $manual" >> $out/nix-support/hydra-build-products
|
2016-07-28 03:27:39 +01:00
|
|
|
|
'';
|
|
|
|
|
|
2010-08-11 13:28:53 +01:00
|
|
|
|
|
2016-09-27 14:26:37 +01:00
|
|
|
|
# Generate the NixOS manpages.
|
|
|
|
|
manpages = runCommand "nixos-manpages"
|
|
|
|
|
{ inherit sources;
|
2018-03-21 19:02:15 +00:00
|
|
|
|
nativeBuildInputs = [ buildPackages.libxml2.bin buildPackages.libxslt.bin ];
|
2016-09-27 14:26:37 +01:00
|
|
|
|
allowedReferences = ["out"];
|
|
|
|
|
}
|
|
|
|
|
''
|
2009-10-05 14:17:45 +01:00
|
|
|
|
# Generate manpages.
|
2013-10-24 19:06:02 +01:00
|
|
|
|
mkdir -p $out/share/man
|
2017-06-28 18:02:33 +01:00
|
|
|
|
xsltproc --nonet \
|
2009-07-14 16:47:03 +01:00
|
|
|
|
--param man.output.in.separate.dir 1 \
|
|
|
|
|
--param man.output.base.dir "'$out/share/man/'" \
|
2009-10-06 00:15:06 +01:00
|
|
|
|
--param man.endnotes.are.numbered 0 \
|
2016-03-19 16:16:59 +00:00
|
|
|
|
--param man.break.after.slash 1 \
|
nixos/doc: Allow refs from options to the manual
My first attempt to do this was to just use a conditional <refsection/>
in order to not create exact references in the manpage but create the
reference in the HTML manual, as suggested by @edolstra on IRC.
Later I went on to use <olink/> to reference sections of the manual, but
in order to do that, we need to overhaul how we generate the manual and
manpages.
So, that's where we are now:
There is a new derivation called "manual-olinkdb", which is the olinkdb
for the HTML manual, which in turn creates the olinkdb.xml file and the
manual.db. The former contains the targetdoc references and the latter
the specific targetptr elements.
The reason why I included the olinkdb.xml verbatim is that first of all
the DTD is dependent on the Docbook XSL sources and the references
within the olinkdb.xml entities are relative to the current directory.
So using a store path for that would end up searching for the manual.db
directly in /nix/store/manual.db.
Unfortunately, the <olinks/> that end up in the output file are
relative, so for example if you're clicking on one of these within the
PDF, the URL is searched in the current directory.
However, the sections from the olink's text are still valid, so we could
use an alternative URL for that in the future.
The manual doesn't contain any links, so even referencing the relative
URL shouldn't do any harm.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
2016-04-11 17:29:00 +01:00
|
|
|
|
--stringparam target.database.document "${olinkDB}/olinkdb.xml" \
|
2018-07-17 21:11:16 +01:00
|
|
|
|
${docbook_xsl_ns}/xml/xsl/docbook/manpages/docbook.xsl \
|
2017-06-28 18:02:33 +01:00
|
|
|
|
${manual-combined}/man-pages-combined.xml
|
2008-01-04 14:24:42 +00:00
|
|
|
|
'';
|
2015-09-24 10:47:00 +01:00
|
|
|
|
|
2011-09-14 19:20:50 +01:00
|
|
|
|
}
|