Skip to content

Conversation

@jsquyres
Copy link
Member

This is a v6.0.x cherry pick PR of main PR #13599

See individual git commit messages for details.

Note that it advances the PRTE submodule hash to the same as master.

Don't search for a .git directory; it might not exist.

Also, remove unnecessary Mercurial and Subversion support; we haven't
used these for years.

Signed-off-by: Jeff Squyres <jeff@squyres.com>
(cherry picked from commit 5e859a9)
Signed-off-by: Jeff Squyres <jeff@squyres.com>
Signed-off-by: Howard Pritchard <howardp@lanl.gov>
(cherry picked from commit 8c027cf)
Use Intersphinx
(https://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html)
for making links out to PMIx and PRTE docs.

If we simply always linked against the https/internet PMIx and PRTE
docs, Intersphinx makes this very easy.  But that's not the Open MPI
way!  Instead, we want to support linking against the internal
(embedded) PMIx and PRTE docs when relevant and possible, mainly to
support fully-offline HTML docs (e.g., for those who operated in
not-connected-to-the-internet scenarios).  As such, there's several
cases that need to be handled properly:

1. When building the internal PMIx / PRTE, link to the local instances
   of those docs (vs. the https/internet instance).  Ensure to use
   relative paths (vs. absolute paths) so that the pre-built HTML docs
   that we include in OMPI distribution tarballs work, regardless of
   the --prefix/etc. used at configure time.

   NOTE: When the Open MPI Sphinx docs are built, we have not yet
   installed the PMIx / PRTE docs.  So create our own (fake)
   objects.inv inventory file for where the PMIx / PRTE docs *will* be
   installed so that Intersphinx can do its deep linking properly.  At
   least for now, we only care about deep links for pmix_info(1) and
   prte_info(1), so we can just hard-code those into those inventory
   files and that's good enough.  If the OMPI docs link more deeply
   into the PMIx / PRTE docs someday (i.e., link to a bunch more
   things than just pmix_info(1) / prte_info(1)), we might need to
   revisit this design decision.

2. When building against an external PMIx / PRTE, make a best guess as
   to where their local HTML doc instance may be (namely:
   $project_prefix/share/doc/PROJECT).  Don't try to handle all the
   possibilities -- it just gets even more complicated than this
   already is.  If we can't find it, just link out to the
   https/internet docs.

Other miscellaneous small changes:

* Added another Python module in docs/requirements.txt (for building
  the Sphinx inventory file).
* Use slightly-more-pythonix dict.get() API calls in docs/conf.py for
  simplicity.
* Updated OMPI PRTE submodule pointer to get a prte_info.1.rst label
  update that works for both upstream PRTE and the OMPI PRTE fork.

Signed-off-by: Jeff Squyres <jeff@squyres.com>
(cherry picked from commit 427b576)
Per the prior commit, update all OMPI docs RST to properly link to
PMIx and PRTE documentation.

Also added a few mpirun(1) links because they were in the vicinity of
the pmix_info(1) and prte_info(1) that were being updates.

Signed-off-by: Jeff Squyres <jeff@squyres.com>
(cherry picked from commit 5b799a0)
@jsquyres jsquyres requested a review from hppritcha January 14, 2026 12:27
@github-actions github-actions bot added this to the v6.0.0 milestone Jan 14, 2026
@hppritcha
Copy link
Member

ignore broken NVIDIA CI.

@hppritcha hppritcha merged commit 9505202 into open-mpi:v6.0.x Jan 14, 2026
16 of 17 checks passed
@jsquyres jsquyres deleted the pr/v6.0.x/tcp-docs-updates branch January 14, 2026 15:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants