-
Notifications
You must be signed in to change notification settings - Fork 200
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
Generate unified Python/C++ docs #1324
Conversation
@@ -55,7 +55,7 @@ using failure_callback_t = std::function<bool(std::size_t, void*)>; | |||
* When implementing a callback function for allocation retry, care must be taken to avoid an | |||
* infinite loop. The following example makes sure to only retry the allocation once: | |||
* | |||
* @code{c++} | |||
* @code{.cpp} |
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 it work to just leave off the {.cpp}
? By default, Doxygen uses the language of the file the @code
is found in. Will that work for the unified case?
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.
Unfortunately doxygen-generated XML does not correctly identify hpp
files as C++ files. It does work for cpp
files, but since rmm's files are all headers I needed to specify this. I do wonder if updating to a newer version of doxygen would improve the situation, and I may test that. I think #1317 needs merging before an y PR to update doxygen, so if the test is promising I'll sequence that work appropriately.
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.
Try modifying the Doxyfile EXTENSION_MAPPING setting?
EXTENSION_MAPPING = cu=C++ \
cuh=C++ \
hpp=C++
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.
That doesn't seem to work, but I'm not sure why. Oddly, specifying @code{.hpp}
works (whether or not hpp is added to the EXTENSION_MAPPING
), but the default inference of just @code
doesn't.
141e98e
to
c5f082d
Compare
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 is a start, but I think this PR is mostly tackling the mechanics of getting RMM Python and C++ APIs unified.
I think the main thing to review here is the generated docs. The RMM C++ API reference is here (requires NVIDIA VPN):
https://downloads.rapids.ai/ci/rmm/pull-request/1324/61abbbc/docs/rmm/html/librmm_api/
I find that very hard to scroll through and read, and there's no table of contents or other useful organization / navigation. It's a wall of (somewhat tiny) text, with very little formatting, font sizes, or HRs to break it up. Also, the order is weird. Ideally this would be broken up conceptually into separate pages about Memory Resources, Containers, Execution Policies, and other concepts. Can we do that with doxygen groups and pages?
Also, there is no differentiation in the TOC to the left between the Python and C++ API References. They both are named "API Reference" (same in the main page here: https://downloads.rapids.ai/ci/rmm/pull-request/1324/61abbbc/docs/rmm/html/)
Also, the page "https://downloads.rapids.ai/ci/rmm/pull-request/1324/61abbbc/docs/rmm/html/basics/" is only about Python, but gets prominent placement as the very first thing. If we are going to unify docs, I think we should give C++ and Python equal footing, like we do in the RMM README.md (which is pretty comprehensive).
I definitely like the idea of integrating the docs, but I think it needs quite a bit of thought and work (and I'm happy to help more).
@harrism you beat me to the punch, time zones are tricky 😄 I had intended to start exactly that conversation during the US workday today. I've kicked that off on Slack, where we can discuss some of these ideas more before coming to any final conclusions here. I completely agree that the current layout is insufficient and we need to do more work. |
I've split out the doxygen fixes uncovered by enabling XML builds into #1348. I'll make a separate PR adding doxygen groups. Once both of those are merged we can revisit this PR using those groupings. |
doxygen catches more doc issues (of the types fixed in #1317) when more build outputs are turned on, which is indicative of some bugs/limitations in doxygen. XML builds will be necessary to leverage Breathe (see #1324) so this PR enables XML builds and fixes the associated issues. Authors: - Vyas Ramasubramani (https://github.com/vyasr) Approvers: - Rong Ou (https://github.com/rongou) URL: #1348
This PR adds doxygen groups for the various parts of the C++ API to help provide more context. This will also help with improving the docs experience in #1324. Authors: - Vyas Ramasubramani (https://github.com/vyasr) Approvers: - Mark Harris (https://github.com/harrism) URL: #1358
7f2e35f
to
ca428fe
Compare
ca428fe
to
5e65212
Compare
5e65212
to
6ec93b4
Compare
All of libcudf's docs have the same issue. I just opened rapidsai/cudf#14341 to remove the extra section. However, that's the section where you would include the summary text that you want I think. So it sounds like what you'd prefer is to instead create a DoxygenLayout file in rmm and move the detailed description for the group to the top of the page. Those are our options, either we remove that section or we fill it in for each group. WDYT? Also feel free to comment on the cudf PR since I assume we'll want similar solutions for both repos.
We control the order, I just alphabetized by default. Please propose an ordering! I'm happy to go with what you think makes sense.
That's coming from this line. I included that because everywhere in the docs where there is anything within the rmm namespace Sphinx tries to create a link, so without this Sphinx throws warnings about missing references. We have three options here:
I'm guessing you prefer 2 or 3, WDYT?
I'd prefer to address this in a follow-up PR. The best ways to fix it would involve using an alternate theme for the documentation, but switching themes will affect more than just the C++ documentation and could involve other changes. I'd prefer to merge this PR largely as is since it makes the Sphinx C++ documentation no worse than the existing Sphinx Python documentation, then come back to improving the overall formatting in a follow-up PR that affects the entire Sphinx docs. In all likelihood this will involve something like https://github.com/rapidsai/sphinx-theme/.
This was caused by the same issue you noticed in the doxygen docs, a mistake in the doxygen. I've fixed that now.
In Sphinx the Search page is empty until you actually perform a search for something
Turns out the module index is specifically designed for Python, so I'll just remove that here. That's an autogenerated page, so not sure how much control we have over it, but if we can modify it I'd say that's a task for a follow-up PR since it's not specific to the unification here.
I agree that we should improve this, but I see similar issues even at the very top level of the documentation so I don't think it's something we should address in this PR. Let's do that in a follow-up to improve the docs overall. |
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.
Here's what I suggest for the ordering.
I think we should fill it in for each group and move it under the title for the page. We can do that in a followup.
Done.
I think (2). I always err on the side of more documentation. :)
Yes please. |
Co-authored-by: Mark Harris <[email protected]>
Since that's focusing on content, let's do that in a follow-up PR where we also add documentation for the groups. |
Agree with all the followups, but can you file an issue with a checklist to capture them all? (can convert the checklist items to individual issues if needed). |
Yup, opened #1368. |
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 have a few related comments on organization. This is such a dramatic improvement that I'm approving and want to ship it. I would support doing all further work in separate PRs.
Welcome to the rmm C++ 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.
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 agree -- never liked the "Welcome to" prefix on practically every Python package's docs.
librmm 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.
This heading makes the breadcrumbs deeply nested. The navigation is awkward as a result.
Can we eliminate this level of the hierarchy entirely, so that it's something more like Home / rmm C++ / API Reference / Memory Resources
? See if you can fuse this page's toctree
into python/docs/cpp.rst
instead.
Welcome to the rmm Python 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.
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.
Looks good to me.
Seems like we no longer need to generate/upload separate librmm
HTML docs, right?
If that's correct, then we should remove the lines below from build_docs.sh
:
https://github.com/vyasr/rmm/blob/9e81c7303816ef53419e8754e9dc5416044eea56/ci/build_docs.sh#L34-L35
Additionally, we'll want to set nightly: 0
in the file below on our documentation site:
/merge |
Description
This PR leverages Breathe to pull the rmm C++ API documentation into the python Sphinx docs build, generating a single unified build of the documentation that supports cross-linking between language libraries and also simplifies cross-linking from other libraries that wish to link here (such as higher-level RAPIDS libraries that use both rmm's Python and C++ APIs).
Using Breathe requires changing the doxygen build to generate XML in addition to the usual HTML. It turns out that doxygen catches more doc issues (of the types fixed in #1317) when more build outputs are turned on, which is indicative of some bugs/limitations in doxygen, but nonetheless I've fixed the additional issues in this PR as well.
Checklist