Commit Graph

9 Commits

Author SHA1 Message Date
David B. Kinder faae669130 doc: properly handle last_updated info for new docs
Update the last_updated extension to correctly handle when new docs are
added and aren't yet commited into git vs. when the list of git folders
isn't correct. Previous PR #7251 incorrectly handled these as the same.

Tracked-On: #7249

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2022-04-04 16:52:29 -07:00
David B. Kinder 0494017f89 doc: handle last updated footer for new document
If a new document is added, the CI system fails because the new document
hasn't been checked into the branch yet so the last_updated.py script
complains with an error.  Change to use the last_published date in this
situation.

Tracked-On: #7249

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2022-04-03 13:45:46 -07:00
David B. Kinder ca9913f34a doc: fix exception error in last_modified processing
When I added a new document that wasn't checked into GitHub yet, the doc
build failed with an unhanded exception:

    Extension error (last_updated):
    (exception: time data '' does not match format '%Y-%m-%d')

Problem is the git query looking up the last commit date for a file
returns an empty string for the date if the file exists but it's not in
the git repo (yet). The subsequent call to strptime raises an exception if passed
an empty string.  This patch handles the exception.

Tracked-On: #7249

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2022-04-02 14:01:44 -07:00
David B. Kinder 81336a8ee4 doc: use Sphinx extension for showing last updated date in footers
Remove the proof-of-concept shell script that post-processes the
generated HTML to add the git date when the corresponding .rst file as
the last modified date, augmenting the existing published date.

Instead, use a custom last_updated.py Sphinx extension that's integrated
into the Sphinx build itself. Remove the old fix-git-modified-date.sh
script and calls to it.

Signed-off-by: David B. Kinder <david.b.kinder@intel.com>
2022-03-18 11:05:50 -07:00
David B. Kinder a2167ae93a doc: add extension to create files and raw links
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>
2020-11-05 09:17:05 -08:00
David B. Kinder e2d3653976 doc: continue doc restructuring
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>
2019-08-01 14:07:22 -07:00
David B. Kinder cb6a3e8f08 doc: prepare for sphinx 2.0 upgrade
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>
2019-05-22 12:43:11 -07:00
David B. Kinder e0260b4496 doc: add sphinx extension improving only directive
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>
2018-11-29 14:38:41 -08:00
David B. Kinder b0deb1b5bd doc: add support for kerneldoc API tools
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>
2018-07-04 18:26:44 -07:00