-
Notifications
You must be signed in to change notification settings - Fork 273
Publish documentation #7149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish documentation #7149
Conversation
* Replace top-level section headings with \page command * Ensure a space between \ingroup and \page for pandoc parsing * Remove link to cprover-manual index from memory-analyzer, restrict-function pointer, etc, and make these pages subpages of the top-level architectural page
* Format index.md as nested lists instead of a list of section headings * Correct broken links * Add blank link before all lists for pandoc parsing * Some end-of-line whitespace removed
* Add README files of doc/API and src/goto-harness * Add surround markdown horizontal rule --- with blank lines for pandoc parsing (pandoc will try to interpret text following --- as yaml).
* Append "last modified" dates to the end of all markdown files. * Use a pandoc filter to rewrite links in cprover-manual (links originally intended to work with the cprover.org/cprover-manual javascripts). * Add a script to repair fenced code blocks written by pandoc
* doc/ADR * doc/API * doc/assets * doc/cprover-manual
Add top-level user guide, reference guide, developer guide pages for the new published documentation. The top-level doxyfile is the original src/doxyfile with minor modification (eg, project title is now "CBMC").
8261342
to
ec26ef5
Compare
Codecov ReportBase: 77.87% // Head: 77.88% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## develop #7149 +/- ##
========================================
Coverage 77.87% 77.88%
========================================
Files 1576 1576
Lines 181824 181867 +43
========================================
+ Hits 141598 141645 +47
+ Misses 40226 40222 -4
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
1. [Introduction](introduction/) | ||
|
||
## 2. [Installation](installation/) | ||
2. [Installation](installation/) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kroening Will this render ok on cprover.org?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I did mention this to @kroening (replacing the sequence of headers with a list) and he did not object.
# Note: Need to read markdown as markdown_phpextra and not default | ||
# markdown to preserve doxygen pragmas like \ingroup. | ||
|
||
# Bug: This is currently interacting badly with \dot in cprover markdown |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To what extent should we be concerned about this? Is there any plan to do something about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This preprocessing is required on the cprover-manual pages as long as they are served up by javascript on prover.org. I did a quick scan of the architectural pages, and I saw no obvious problems caused by omitting this preprocessing on the current set of pages. But I think doxygen's brittle treatment of markdown files is a potential issue, and I think we would be better off just deciding to write doxygen-friendly markdown and just living with subpar rendering by other tools (like on github).
The content of nondet-volatile.md and restrict-function-pointer.md in doc/architectural has already been moved to the goto-instrument man page. Remove this also from architectural main page front-page.md
This doxygen file is based on src/doxyfile, and src/doxyfile can be removed once the run_doxygen continuous integration check is disabled.
1eb7041
to
947d3f3
Compare
I'd like to see this adopted so that documentation can be maintained more easily and directly from GitHub, and browsable within GitHub and local repos. Further, I'd like to see is declare "Doxygen" and "MarkDown as spoken by Doxygen" become our expected documentation method, which would allow us to strip away a little of the scripting complexity Mark added to support the Markdown as it is today. But, that can wait. Please let's get this in. |
@jimgrundy Hi Jim, this is on my plate for today - will get this reviewed, but then I'm not sure who else this needs reviews from. I'll see if it needs a couple more from our end if I can chase them further (but please be aware that we've been hit by unexpected illness in our team, so we're missing some of our usual bandwidth). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some minor comments that don't diminish the ability of this to move forward.
Thank you for your efforts to bring the documentation up to date.
doc/API/README.md
Outdated
@@ -0,0 +1,3 @@ | |||
# CProver APIs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be changed to something like:
\page apis CPROVER APIs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This particular proposal won't work because this is the main markdown file for doc/API
. The folders doc/API
, doc/ADR
, and doc/assets
are built separately because they don't seem to be linked into the main CPROVER documentation.
I've taken the liberty of converting doc/API
and doc/ADR
to the doxygen page/subpage syntax.
I was going to do the same for doc/assets
, but there is an xml-spec.md that is not linked to by the top-level README, and I wasn't sure which of the various specs are considered authoritative.
doc/doxygen-root/README.md
Outdated
* On MacOS, | ||
we recommend installing with [brew](https://brew.sh/): | ||
``` | ||
brew install doxygen graphviz |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need pandoc
as well?
I tried without and got some errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added pandoc to the instructions. I omitted it because it is already installed on the GitHub ubuntu runner. But good catch.
doc/doxygen-root/README.md
Outdated
To build the documentation, run | ||
|
||
``` | ||
doxygen |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's also a Makefile
.
I tried running the default
action of the Makefile
first, but got a very broken version of the documentation (probably because I was missing stuff from the dependencies?) - which one is the defacto way a developer builds documentation locally? Just running Doxygen
, or the Makefile
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. There is now a makefile to automate the five or six invocations of doxygen. The current build command is "make".
doc/doxygen-root/README.md
Outdated
|
||
## Contribute documentation | ||
|
||
Coming soon... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There appears to be some documentation on this at contributing.md
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a link. Thanks.
@@ -0,0 +1,60 @@ | |||
# CBMC documentation |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this readme file be lifted to the top-level of the documentation folder, or does it conflict with the compilation of the documentation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could go either way. My intention is that this documents the process of building the documentation, and so doesn't belong in the documentation itself. I'm leaving it out for now.
doc/doxygen-root/developer_guide.md
Outdated
* \ref cprover_documentation | ||
* [CProver Architecture Decision Records](adr/index.html) | ||
* [CProver APIs](api/index.html) | ||
* [CProver assets](assets/index.html) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: s/assets/Assets/g
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
0781a2a
to
ee0a06d
Compare
This pull request proposes a method of publishing documentation in the diffblue/cbmc repository to the diffblue.github.io/cbmc web site. See this comment for a discussion of the goals. See markrtuttle.github.io/cbmc-documentation for a demonstration.
After merging this pull request, the diffblue/cbmc repository must be configured to publish pages from the branch
gh-pages
to diffblue.github.io/cbmc. See github instructions to configure from within the account settings (basically two clicks).There are many known issues. A lot of these comments have to do with using pandoc to remove doxygen issues from markdown files before running doxygen. It is nearly impossible to write markdown files that format cleanly with doxygen and two versions of pandoc and still read well on github as rendered markdown (and still work well with the javascript rendering www.cprover.org/cprover-manual). The biggest issue is that doxygen is written to render markdown snippets from code comments, but does not handle well a collection of basic markdown files that interlink among themselves using classical markdown syntax. Most important, doxygen wants explicitly-declared, globally-unique labels in markdown (that is not supported by classical markdown) for links, and does not follow markdown syntax for linking to sections within a markdown file. We need to make a decision about whether we are writing markdown or doxygen markdown. I recommend (sigh) doxygen markdown and using
\page unique-label Heading
in place of# Heading
. For section labels, without requiring unique section names, the only option appears to be\section unique-label Section
in place of## Section
, but that is a massive revision (or just give up on linking directly to section headers).The modern brew doxygen is 1.9.5 and the ubuntu-latest doxygen on github is 1.8.17. The older version 1.8.17 appears to differ slightly between brew and ubuntu (eg, volume of progress information printed during execution). The newer version 1.9.5 issues warnings that the older version 1.8.17 does not. Differences include some unused variables in doxyfile that are now obsolete, and 500+ new warnings of the form
This pull request restores two files that may have been deleted from develop:
goto-cc has broken links (what should they link to?):
test_suite.md a broken link (what should it link to?):
pandoc cannot handle lists or rules that are not preceded by a blank line. In particular, it will try to interpret text immediately following the horizontal rule
---
as yaml.pandoc --read markdown sometimes treats doxygen commands like \ingroup as latex commands. Using pandoc --read markdown_phpextra avoids this problem.
pandoc --read markdown_phpextra sometimes deletes or modifies fenced code blocks with syntax highlighting like ```c. Using pandoc --read markdown avoids this problem.
doxygen cannot handle links
[hyper link](url)
that break over two lines. Using pandoc --wrap none solves this problem, but now what to use for --read and --write formats (see above).cprover-manual has mutliple sections with same title resulting in nonunique labels for doxygen. Doxygen cannot link to internal sections with
[section](#section)
. Doxygen requires globally unique section labels. This is not supported in straight markdown. The pandoc --write markdown_phpextra will generate the needed section labels, but doxygen complains because they are not unique. For example, in the contracts pages, there are multiple sections named "Overview".cprover-manual does not have top-level sections, and doxygen complains it has subsections outside of sections, etc.