Links to files in the GitHub repo's master branch should be to the files
within the branch being generated. For example, in the v2.1
documentation, links should be to the v2.1 branch contents. (Previously
links were being made to the master branch in all our archived content.)
This creates a problem when we want to remove an obsolete file in the
master branch but can't because older documentaiton incorrectly depends
on it.
This new extension defines a :acrn_file: and :acrn_raw: role that will
create links to the given file within the current commit branch.
This PR also replaces docs with hard-coded links to files in the master
branch with uses of these new roles to create links to files.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Changing the folder structure will cause too many broken links for
external references (from other sites). So, let's put the content back
where it was before the reorg, and instead use the new persona-based
navigation to point to documents in the original locations.
Also, introduce redirects for some documents that no longer exits.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Sphinx 2.0 reports some "expected errors" differently, so add the new
message patterns to our known-errors scanning.
Also, the kerneldoc tool has a problem with sphinx 2.0, but a fix was
available.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
The Sphinx .. only:: directive is limited to handling only conditional
text and can't handling conditional use of directives. For example,
.. only:: test
.. automodule:: west.runners.core
:members:
is not handled. This PR monkey patches the handling of the existing
.. only:: directive done by Sphinx.
See https://github.com/pfalcon/sphinx_selective_exclude for details.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
Some ACRN kernel components are using the API documentation methods of
the Linux kernel. While they use Sphinx for generating their
documentation, they don't use doxygen to collect the API information as
we do for the rest of the project. Instead, they use their own tools
called "kerneldoc". This PR incorporates those tools into our
documentation build process.
There is a prescribed directory structure for this to work: that the
acrn-hypervisor and acrn-kernel repos are cloned to sibling folders,
e.g.:
projectacrn
acrn-hypervisor
acrn-kernel
so that documentation references from acrn_hypervisor/doc can access the
source code in ../../acrn-kernel to do the kerneldoc processing. A full
display of the kerneldoc API material for a source file in the
acrn-kernel tree can be done using a sphinx extension directive:
.. kernel-doc:: /tools/virtio/linux/scatterlist.h
where the assumed root of these file references is ../../acrn-kernel.
The format for kerneldoc comments is documented in
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html and
references to kerneldoc API material in .rst files is documented in
https://www.kernel.org/doc/html/latest/doc-guide/kernel-doc.html#including-kernel-doc-comments
Without options, the kernel-doc directive includes all documentation
comments from the source file. With options, you can display subsets of
these comments.
The intention is to limit use of kerneldoc comments to the acrn-kernel
repo and not use them elsewhere within the ACRN project (where doxygen
comments are expected.)
While I'd prefer NOT to include the kerneldoc perl script here (it is
already in the acrn-kernel/sphinx folder), I don't want to create a
dependency on the acrn-kernel folder existing for documentation
generation, but this might be unavoidable once we have part of the API
material coming from there. We can update this in a later PR.
Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
David B. Kinder