Skip to content

Odoc rules: Generate full docs#7840

Closed
jonludlam wants to merge 6 commits intoocaml:mainfrom
jonludlam:odoc-rules-v11
Closed

Odoc rules: Generate full docs#7840
jonludlam wants to merge 6 commits intoocaml:mainfrom
jonludlam:odoc-rules-v11

Conversation

@jonludlam
Copy link
Copy Markdown
Member

This PR introduces new rules to build the documentation for all of the
dependent libraries used by a project, including those installed in the switch rather than in the workspace.

The primary target for this is to ensure we have up-to-date correct and complete docs for the workspace, both for browsing and for tooling to be able to query.

A few decisions made during this:

  1. Only libraries that are used by the projects in the workspace are documented.

There's no attempt made to document the entire switch. This has some
interesting consequences - for example, documentation files (mlds) are associated with packages rather than libraries and may well assume the existence of all their libraries.

  1. Odoc file locations

The odoc files produced from the cmti/cmt/cmi files in the switch are put into 'equivalent' dirs under _build - specifically if a cmti file is in <opam-switch>/lib/foo/bar then the odoc file will be in _build/default/_doc/odoc/external/foo/bar. This is done to ensure consistency between odoc's view of the world and ocaml's, as odoc uses the same strategy as ocaml for finding modules, that is, an include path.

  1. Non-dune packages

There's a bare-minimum level of effort put into handling non-dune packages. Essentially I've not tried to separate things into separate libraries, and the packages are just treated like a big bag of modules.

  1. Unwrapped libraries

These are also treated like the non-dune packages - this is mainly because I couldn't see a good way to get a Modules.t value.

  1. Private libraries

Since the primary target is for the developer working on the codebase, I'm building docs for the private libraries by default.

Still to do:

This is a draft right now - I've not updated the tests. In addition, there's other work to be done - possibly in this PR or a follow-up.

  • make the index pages more interesting (ie, more metadata to document).
  • silence the warnings coming from files that aren't in the workspace
  • Add a symlink from the previous docs output directory (or possibly a 403 page!)
  • Do a better job of stdlib

@jonludlam jonludlam marked this pull request as draft May 30, 2023 11:46
@jonludlam
Copy link
Copy Markdown
Member Author

Example output, from running dune build @doc on dune itself here: https://jon.ludl.am/experiments/all-the-dune-docs/index.html

@rgrinberg rgrinberg added the odoc Issues and PRs related to documentation generation with odoc label Jun 8, 2023
@rgrinberg
Copy link
Copy Markdown
Member

Some minor remarks:

  • We use American spelling elsewhere in the project. So Artefact -> Artifact.
  • Our naming convention is Foo_bar over FooBar.

A couple more questions about the generated docs:

  • Why does bin_prot have its own directory? It's a dune project so I'm surprised it has a special install layout.
  • Can we exclude private libraries with inline tests somehow? It doesn't make sense to include them I think

@jonludlam
Copy link
Copy Markdown
Member Author

Good question about bin_prot. The superficial answer is that I dont have a Modules.t value for it - and I believe that's because in the installed dune-package file there's only:

(lang dune 3.6)
(use_meta)

but I'm not quite sure why we've only got that.

@jonludlam
Copy link
Copy Markdown
Member Author

For the inline test libraries, I agree it would be nice to exclude them. That'll be pretty easy if I can identify them precisely -- do you know the best way to do this?

@jonludlam
Copy link
Copy Markdown
Member Author

The big change since the first iteration of this is that dune build @doc now does something pretty similar to what currently happens -- ie, building the docs for the local packages -- whereas dune build @doc-all builds all of the docs. I've also made more use of aliases for the html output to avoid unnecessary 'fake' dependencies. I've been testing it with --sandbox xxx to see if that works, but something is going wrong there at the link phase, and I'm not sure I know the best way to debug this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

odoc Issues and PRs related to documentation generation with odoc

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants