unikernel/duniverse/dune_/doc/reference/actions/bash.rst

@@ -0,0 +1,12 @@
+bash
+----
+
+.. highlight:: dune
+
+.. describe:: (bash <cmd>)
+
+   Execute a command using ``/bin/bash``. This is obviously not very portable.
+
+   Example::
+
+   (bash "echo $PATH")

unikernel/duniverse/dune_/doc/reference/actions/cat.rst

@@ -0,0 +1,12 @@
+cat
+---
+
+.. highlight:: dune
+
+.. describe:: (cat <file> ...)
+
+   Sequentially print the contents of files to stdout.
+
+   Example::
+
+   (cat data.txt)

unikernel/duniverse/dune_/doc/reference/actions/chdir.rst

@@ -0,0 +1,13 @@
+chdir
+-----
+
+.. highlight:: dune
+
+.. describe:: (chdir <dir> <DSL>)
+
+   Run an action in a different directory.
+
+   Example::
+
+     (chdir src
+      (run ./build.exe))

unikernel/duniverse/dune_/doc/reference/actions/cmp.rst

@@ -0,0 +1,13 @@
+cmp
+---
+
+.. highlight:: dune
+
+.. describe:: (cmp <file1> <file2>)
+
+   ``(cmp <file1> <file2>)`` is similar to ``(run cmp <file1> <file2>)`` but
+   allows promotion. See :doc:`/concepts/promotion` for more details.
+
+   Example::
+
+   (cmp bin.expected bin.output)

unikernel/duniverse/dune_/doc/reference/actions/concurrent.rst

@@ -0,0 +1,19 @@
+concurrent
+----------
+
+.. highlight:: dune
+
+.. describe:: (concurrent <DSL> ...)
+
+   Execute several commands concurrently and collect all resulting errors, if any.
+
+   .. warning:: The concurrency is limited by the ``-j`` flag passed to Dune.
+      In particular, if Dune is running with ``-j 1``, these commands will
+      actually run sequentially, which may cause a deadlock if they talk to
+      each other.
+
+   Example::
+
+     (concurrent
+      (run ./proga.exe)
+      (run ./progb.exe))

unikernel/duniverse/dune_/doc/reference/actions/copy#.rst

@@ -0,0 +1,27 @@
+copy#
+-----
+
+.. highlight:: dune
+
+.. describe:: (copy# <src> <dst>)
+
+   Copy a file and add a line directive at the beginning.
+
+   Example::
+
+   (copy# config.windows.ml config.ml)
+
+   More precisely, ``copy#`` inserts the following line:
+
+   .. code:: ocaml
+
+      # 1 "<source file name>"
+
+   Most languages recognize such lines and update their current location to
+   report errors in the original file rather than the copy. This is important
+   because the copy exists only under the ``_build`` directory, and in order
+   for editors to jump to errors when parsing the build system's output, errors
+   must point to files that exist in the source tree. In the beta versions of
+   Dune, ``copy#`` was called ``copy-and-add-line-directive``. However, most of
+   time, one wants this behavior rather than a bare copy, so it was renamed to
+   something shorter.

unikernel/duniverse/dune_/doc/reference/actions/copy.rst

@@ -0,0 +1,14 @@
+copy
+----
+
+.. highlight:: dune
+
+.. describe:: (copy <src> <dst>)
+
+   Copy a file. If these files are OCaml sources, you should follow the
+   ``module_name.xxx.ml`` :ref:`naming convention <merlin-filenames>` to
+   preserve Merlin's functionality.
+
+   Example::
+
+   (copy data.txt.template data.txt)

unikernel/duniverse/dune_/doc/reference/actions/diff.rst

@@ -0,0 +1,14 @@
+diff
+----
+
+.. highlight:: dune
+
+.. describe:: (diff <file1> <file2>)
+
+   ``(diff <file1> <file2>)`` is similar to ``(run diff <file1> <file2>)`` but
+   is better and allows promotion. See :doc:`/concepts/promotion` for more
+   details.
+
+   Example::
+
+   (diff test.expected test.output)

unikernel/duniverse/dune_/doc/reference/actions/diffq.rst

@@ -0,0 +1,16 @@
+diff?
+-----
+
+.. highlight:: dune
+
+.. describe:: (diff? <file1> <file2>)
+
+   ``(diff? <file1> <file2>)`` is similar to ``(diff <file1> <file2>)`` except
+   that ``<file2>`` should be produced by a part of the same action rather than
+   be a dependency, is optional and will be consumed by ``diff?``.
+
+   Example::
+
+     (progn
+      (with-stdout-to test.output (run ./test.exe))
+      (diff? test.expected test.output))

unikernel/duniverse/dune_/doc/reference/actions/dynamic-run.rst

@@ -0,0 +1,13 @@
+dynamic-run
+-----------
+
+.. highlight:: dune
+
+.. describe:: (dynamic-run <prog> <args>)
+
+   Execute a program that was linked against the ``dune-action-plugin`` library.
+   ``<prog>`` is resolved in the same way as in :doc:`run`.
+
+   Example::
+
+   (dynamic-run ./plugin.exe)

unikernel/duniverse/dune_/doc/reference/actions/echo.rst

@@ -0,0 +1,12 @@
+echo
+----
+
+.. highlight:: dune
+
+.. describe:: (echo <string>)
+
+   Output a string on ``stdout``.
+
+   Example::
+
+   (echo "Hello, world")

unikernel/duniverse/dune_/doc/reference/actions/format-dune-file.rst

@@ -0,0 +1,14 @@
+cat
+---
+
+.. highlight:: dune
+
+.. describe:: (format-dune-file <src> <dst>)
+
+   Output the formatted contents of the file ``<src>`` to ``<dst>``. The source
+   file is assumed to contain S-expressions. Note that the precise formatting
+   can depend on the version of the Dune language used by containing project.
+
+   Example::
+
+   (format-dune-file file.sexp file.sexp.formatted)

unikernel/duniverse/dune_/doc/reference/actions/ignore-outputs.rst

@@ -0,0 +1,14 @@
+ignore-<outputs>
+----------------
+
+.. highlight:: dune
+
+.. describe:: (ignore-<outputs> <DSL>)
+
+   Ignore the output, where ``<outputs>`` is one of: ``stdout``, ``stderr``, or
+   ``outputs``.
+
+   Example::
+
+     (ignore-stderr
+      (run ./get-conf.exe))

unikernel/duniverse/dune_/doc/reference/actions/index.rst

@@ -0,0 +1,120 @@
+Actions
+=======
+
+.. highlight:: dune
+
+``(action ...)`` fields describe user actions.
+
+User actions are always run from the same subdirectory of the current build
+context as the ``dune`` file they are defined in, so for instance, an action defined
+in ``src/foo/dune`` will be run from ``$build/<context>/src/foo``.
+
+The argument of ``(action ...)`` fields is a small DSL that's interpreted by
+Dune directly and doesn't require an external shell. All atoms in the DSL
+support :doc:`/concepts/variables`. Moreover, you don't need to specify
+dependencies explicitly for the special ``%{<kind>:...}`` forms; these are
+recognized and automatically handled by Dune.
+
+The DSL is currently quite limited, so if you want to do something complicated,
+it's recommended to write a small OCaml program and use the DSL to invoke it.
+You can use `shexp <https://github.com/janestreet/shexp>`__ to write portable
+scripts or :ref:`configurator` for configuration related tasks. You can also
+use :ref:`dune-action-plugin` to express program dependencies directly in the
+source code.
+
+The following constructions are available:
+
+.. grid:: 1 1 2 2
+
+  .. grid-item::
+  
+    .. toctree::
+       :caption: Running commands
+    
+       run
+       system
+       bash
+       dynamic-run
+       chdir
+       setenv
+       with-accepted-exit-codes
+
+  .. grid-item::
+
+    .. toctree::
+       :caption: Input and output
+    
+       echo
+       with-outputs-to
+       with-stdin-from
+       ignore-outputs
+       cat
+       copy
+       copy#
+       write-file
+       pipe-outputs
+       format-dune-file
+
+  .. grid-item::
+
+    .. toctree::
+       :caption: Comparing files
+    
+       diff
+       diffq
+       cmp
+
+  .. grid-item::
+
+    .. toctree::
+       :caption: Control structures
+    
+       progn
+       concurrent
+       no-infer
+
+Note: expansion of the special ``%{<kind>:...}`` is done relative to the current
+working directory of the DSL being executed. So for instance, if you
+have this action in a ``src/foo/dune``:
+
+.. code:: dune
+
+    (action (chdir ../../.. (echo %{dep:dune})))
+
+Then ``%{dep:dune}`` will expand to ``src/foo/dune``. When you run various
+tools, they often use the filename given on the command line in error messages.
+As a result, if you execute the command from the original directory, it will
+only see the basename.
+
+To understand why this is important, let's consider this ``dune`` file living in
+``src/foo``::
+
+  (rule
+   (target blah.ml)
+   (deps blah.mll)
+   (action
+    (run ocamllex -o %{target} %{deps})))
+
+Here the command that will be executed is:
+
+.. code:: console
+
+  $ ocamllex -o blah.ml blah.mll
+
+And it will be executed in ``_build/<context>/src/foo``. As a result, if there
+is an error in the generated ``blah.ml`` file, it will be reported as:
+
+::
+
+    File "blah.ml", line 42, characters 5-10:
+    Error: ...
+
+Which can be a problem, as your editor might think that ``blah.ml`` is at the root
+of your project. Instead, this is a better way to write it::
+
+  (rule
+   (target blah.ml)
+   (deps blah.mll)
+   (action
+    (chdir %{workspace_root}
+     (run ocamllex -o %{target} %{deps}))))

unikernel/duniverse/dune_/doc/reference/actions/no-infer.rst

@@ -0,0 +1,17 @@
+no-infer
+--------
+
+.. highlight:: dune
+
+.. describe:: (no-infer <DSL>)
+
+   Perform an action without inference of dependencies and targets. This is
+   useful if you are generating dependencies in a way that Dune doesn't know
+   about, for instance by calling an external build system.
+
+   Example::
+
+     (no-infer
+      (progn
+       (run make)
+       (copy mylib.a lib.a)))

unikernel/duniverse/dune_/doc/reference/actions/pipe-outputs.rst

@@ -0,0 +1,18 @@
+pipe-<outputs>
+--------------
+
+.. highlight:: dune
+
+.. describe:: (pipe-<outputs> <DSL> <DSL> <DSL>...)
+
+   .. versionadded:: 2.7
+
+   Execute several actions (at least two) in sequence, filtering the
+   ``<outputs>`` of the first command through the other command, piping the
+   standard output of each one into the input of the next.
+
+   Example::
+
+      (pipe-stdout
+       (run ./list-tests.exe)
+       (run ./exec-tests.exe))

unikernel/duniverse/dune_/doc/reference/actions/progn.rst

@@ -0,0 +1,14 @@
+progn
+-----
+
+.. highlight:: dune
+
+.. describe:: (progn <DSL> ...)
+
+   Execute several commands in sequence.
+
+   Example::
+
+     (progn
+      (run ./proga.exe)
+      (run ./progb.exe))

unikernel/duniverse/dune_/doc/reference/actions/run.rst

@@ -0,0 +1,13 @@
+run
+---
+
+.. highlight:: dune
+
+.. describe:: (run <prog> <args>)
+
+   Execute a program. ``<prog>`` is resolved locally if it is available in the
+   current workspace, otherwise it is resolved using the ``PATH``.
+
+   Example::
+
+   (run capnp compile -o %{bin:capnpc-ocaml} schema.capnp)

unikernel/duniverse/dune_/doc/reference/actions/setenv.rst

@@ -0,0 +1,14 @@
+setenv
+------
+
+.. highlight:: dune
+
+.. describe:: (setenv <var> <value> <DSL>)
+
+   Run an action with an environment variable set.
+
+   Example::
+
+     (setenv
+       VAR value
+       (bash "echo $VAR"))

unikernel/duniverse/dune_/doc/reference/actions/system.rst

@@ -0,0 +1,12 @@
+system
+------
+
+.. highlight:: dune
+
+.. describe:: (system <cmd>)
+
+   Execute a command using the system shell: ``sh`` on Unix and ``cmd`` on Windows.
+
+   Example::
+
+   (system "command arg1 arg2")

unikernel/duniverse/dune_/doc/reference/actions/with-accepted-exit-codes.rst

@@ -0,0 +1,20 @@
+with-accepted-exit-codes
+------------------------
+
+.. highlight:: dune
+
+.. describe:: (with-accepted-exit-codes <pred> <DSL>)
+
+   .. versionadded:: 2.0
+
+   Specifies the list of expected exit codes for the programs executed in
+   ``<DSL>``. ``<pred>`` is a predicate on integer values, and it's specified
+   using the :doc:`/reference/predicate-language`. ``<DSL>`` can only contain
+   nested occurrences of ``run``, ``bash``, ``system``, ``chdir``, ``setenv``,
+   ``ignore-<outputs>``, ``with-stdin-from``, and ``with-<outputs>-to``.
+
+   Example::
+
+     (with-accepted-exit-codes
+      (or 1 2)
+      (run false))

unikernel/duniverse/dune_/doc/reference/actions/with-outputs-to.rst

@@ -0,0 +1,14 @@
+with-<outputs>-to
+-----------------
+
+.. highlight:: dune
+
+.. describe:: (with-<outputs>-to <file> <DSL>)
+
+   Redirect the output to a file, where ``<outputs>`` is one of: ``stdout``,
+   ``stderr`` or ``outputs`` (for both ``stdout`` and ``stderr``).
+
+   Example::
+
+     (with-stdout-to conf.txt
+      (run ./get-conf.exe))

unikernel/duniverse/dune_/doc/reference/actions/with-stdin-from.rst

@@ -0,0 +1,13 @@
+with-stdin-from
+---------------
+
+.. highlight:: dune
+
+.. describe:: (with-stdin-from <file> <DSL>)
+
+   Redirect the input from a file.
+
+   Example::
+
+     (with-stdin-from data.txt
+      (run ./tests.exe))

unikernel/duniverse/dune_/doc/reference/actions/write-file.rst

@@ -0,0 +1,12 @@
+write-file
+----------
+
+.. highlight:: dune
+
+.. describe:: (write-file <file> <string>)
+
+   Writes ``<string>`` to ``<file>``.
+
+   Example::
+
+   (write-file users.txt jane,joe)

unikernel/duniverse/dune_/doc/reference/aliases.rst

@@ -0,0 +1,93 @@
+Aliases
+=======
+
+:term:`Aliases <alias>` are build targets that do not correspond to specific
+files. For example, the ``runtest`` alias corresponds to running tests.
+
+Model and Syntax
+----------------
+
+Dependencies and actions can be attached to an alias. When this alias is
+requested to be built, these dependencies are built and these actions are
+executed. Aliases are attached to specific directories.
+
+In commands such as ``dune build``, the syntax to refer to the ``x`` alias is
+``@x``, for example ``dune build @x``. This is why it is common to refer to it
+as "the ``@x`` alias", or "attaching a rule to ``@x``".
+
+Building ``@x`` will build ``x`` in all subdirectories of the current
+directory. This is the most common case, but it is possible to restrict this
+using different syntaxes:
+
+- ``@sub/dir/x`` will build ``x`` in ``sub/dir`` and its subdirectories.
+- ``@@x`` will build ``x`` in the current directory only.
+- ``@@sub/dir/x`` will build ``x`` in ``sub/dir`` only.
+
+If ``dir`` is the directory of a :term:`build context`, it restricts the alias
+to this context.
+
+To summarize, the syntax is:
+
+- ``@`` (recursive) or ``@@`` (non-recursive): determine if subdirectories are
+  included
+- optional :term:`build context root`: restrict to a particular :term:`build
+  context`
+- optional directory: only consider this subdirectory
+- alias name
+
+Examples:
+
+- ``dune build @_build/foo/runtest`` only runs the tests for
+  the ``foo`` build context
+- ``dune build @runtest`` will run the tests for all build contexts
+
+User-Defined Aliases
+--------------------
+
+It is possible to use any name for alias names; it will then be available on
+the command line. For example, if a Dune file contains the following, then
+``dune build @deploy`` will execute that command.
+
+.. code:: dune
+
+   (rule
+    (alias deploy)
+    (action ./run-deployer.exe))
+
+Built-In Aliases
+----------------
+
+Some aliases are defined and managed by Dune itself:
+
+.. grid:: 1 3 2 3
+
+  .. grid-item::
+
+    .. toctree::
+       :caption: Builds
+
+       aliases/all
+       aliases/default
+       aliases/install
+       aliases/pkg-install
+       aliases/empty
+
+  .. grid-item::
+
+    .. toctree::
+       :caption: Checks
+
+       aliases/check
+       aliases/ocaml-index
+       aliases/runtest
+       aliases/fmt
+       aliases/lint
+
+  .. grid-item::
+
+    .. toctree::
+       :caption: Docs
+
+       aliases/doc
+       aliases/doc-private
+       aliases/doc-json

unikernel/duniverse/dune_/doc/reference/aliases/all.rst

@@ -0,0 +1,9 @@
+@all
+====
+
+This alias corresponds to every known file target in a directory.
+
+Since version 2.0 of the dune language, JS targets of executables are no longer
+included in the `all` alias by default. To get back the old behavior of
+including the JS targets in `all`, one can add the ``js`` target to the
+executable's ``modes`` field.

unikernel/duniverse/dune_/doc/reference/aliases/check.rst

@@ -0,0 +1,11 @@
+@check
+======
+
+This alias corresponds to the set of targets necessary for development tools to
+work correctly. For example, it will build ``*.cmi``, ``*.cmt``, and ``*.cmti``
+files so that Merlin and ``ocaml-lsp-server`` can be used in the project.
+It is also useful in the development loop because it will catch compilation
+errors without executing expensive operations such as linking executables.
+
+.. seealso:: :doc:`ocaml-index` for a fast feedback loop that
+   also indexes the project.

unikernel/duniverse/dune_/doc/reference/aliases/default.rst

@@ -0,0 +1,27 @@
+@default
+========
+
+This alias corresponds to the default argument for ``dune build``: ``dune
+build`` is equivalent to ``dune build @@default`` (``@@`` indicates a
+:doc:`non-recursive alias <../aliases>`). Similarly, ``dune build dir`` is
+equivalent to ``dune build @@dir/default``.
+
+When a directory doesn't explicitly define what the ``default`` alias means via
+an :doc:`/reference/dune/alias` stanza, the following implicit definition is
+assumed:
+
+.. code:: dune
+
+   (alias
+    (name default)
+    (deps (alias_rec all)))
+
+But if such a stanza is present in the ``dune`` file in a directory, it will be
+used instead. For example, if the following is present in ``tests/dune``,
+``dune build tests`` will run tests there:
+
+.. code:: dune
+
+   (alias
+    (name default)
+    (deps (alias_rec runtest)))

unikernel/duniverse/dune_/doc/reference/aliases/doc-json.rst

@@ -0,0 +1,6 @@
+@doc-json
+=========
+
+This alias builds documentation for public libraries as JSON files. These are
+produced by ``odoc``'s option ``--as-json`` and can be consumed by external
+tools.

unikernel/duniverse/dune_/doc/reference/aliases/doc-private.rst

@@ -0,0 +1,4 @@
+@doc-private
+============
+
+This alias builds documentation for all libraries, both public & private.

unikernel/duniverse/dune_/doc/reference/aliases/doc.rst

@@ -0,0 +1,6 @@
+@doc
+====
+
+This alias builds documentation for public libraries as HTML pages.
+
+.. seealso:: :doc:`/documentation`

unikernel/duniverse/dune_/doc/reference/aliases/empty.rst

@@ -0,0 +1,9 @@
+@empty
+======
+
+The `empty` alias contains no targets.
+
+As of Dune language version 3.20, user-defined :doc:`rule <../dune/rule>` and
+:doc:`alias <../dune/alias>` stanzas are no longer permitted to extend the
+`empty` alias.
+

unikernel/duniverse/dune_/doc/reference/aliases/fmt.rst

@@ -0,0 +1,24 @@
+@fmt
+====
+
+This alias is used by formatting rules: when it is built, code formatters will
+be executed (using :doc:`promotion </concepts/promotion>`).
+
+``dune fmt`` is a shortcut for ``dune build @fmt --auto-promote``.
+
+It is possible to build on top of this convention. If some actions are manually
+attached to the ``fmt`` alias, they will be executed by ``dune fmt``.
+
+Example:
+
+.. code:: dune
+
+   (rule
+    (with-stdout-to
+     data.json.formatted
+     (run jq . %{dep:data.json})))
+
+   (rule
+    (alias fmt)
+    (action
+     (diff data.json data.json.formatted)))

unikernel/duniverse/dune_/doc/reference/aliases/install.rst

@@ -0,0 +1,6 @@
+@install
+========
+
+Building this alias will create the ``*.install`` files used by the :doc:`opam
+integration </explanation/opam-integration>`. In turn, these depend on
+installable files.

unikernel/duniverse/dune_/doc/reference/aliases/lint.rst

@@ -0,0 +1,4 @@
+@lint
+=====
+
+This alias runs linting tools.

unikernel/duniverse/dune_/doc/reference/aliases/ocaml-index.rst

@@ -0,0 +1,9 @@
+@ocaml-index
+============
+
+This alias corresponds to the set of targets necessary for development tools to
+provide project-wide queries such as "get all references of this value". These
+targets are indexes built using the required `ocaml-index` binary. Since this
+alias also includes the ``*.cmi``, ``*.cmt``, and ``*.cmti`` files usually built
+by ``check``, it can be used in most projects as a replacement to get a fast
+feedback loop while maintaining the indexes up-to-date.

unikernel/duniverse/dune_/doc/reference/aliases/pkg-install.rst

@@ -0,0 +1,23 @@
+@pkg-install
+============
+
+This alias is only relevant when using Dune with *package management* (see
+:doc:`/tutorials/dune-package-management/index`). Running ``dune build
+@pkg-install`` will fetch the dependencies described in the ``depends`` field
+of your ``dune-project`` (see :doc:`/reference/dune-project/package`) and build
+them. It will not build your project.
+
+Indeed, if you need to build the project, you need to use the regular ``dune
+build`` command. Note that if the dependencies have not been already fetch and
+downloaded, ``dune build`` will **also** take care of getting and building them.
+
+.. note::
+    ``dune build @pkg-install`` is particularly useful when you are building
+    projects using per-layer caching systems, e.g., Docker images. Using this
+    alias, you will be able to cache the dependencies building stage as they
+    change less regularly.
+
+If you are building the ``@pkg-install`` alias in a repository where package
+management is not activated, the command will fail.
+
+.. seealso:: :doc:`/explanation/package-management`

unikernel/duniverse/dune_/doc/reference/aliases/runtest.rst

@@ -0,0 +1,10 @@
+@runtest
+========
+
+Actions that run tests are attached to this alias. For example this convention
+is used by the ``(test)`` stanza.
+
+``dune runtest`` is a shortcut for ``dune build @runtest`` but is also able to
+run individual tests.
+
+.. seealso:: :doc:`/tests`

unikernel/duniverse/dune_/doc/reference/boolean-language.rst

@@ -0,0 +1,25 @@
+Boolean Language
+================
+
+The Boolean language allows the user to define simple Boolean expressions that
+Dune can evaluate. Here's a semiformal specification of the language:
+
+.. productionlist:: blang
+   op : '=' | '<' | '>' | '<>' | '>=' | '<='
+   expr : (and <expr>+)
+        : (or <expr>+)
+        : (<op> <template> <template>)
+        : (not <expr>)
+        : <template>
+
+After an expression is evaluated, it must be exactly the string ``true`` or
+``false`` to be considered as a Boolean. Any other value will be treated as an
+error.
+
+Below is a simple example of a condition expressing that the build
+has a Flambda compiler, with the help of variable expansion, and is
+targeting OSX:
+
+.. code:: dune
+
+   (and %{ocaml-config:flambda} (= %{ocaml-config:system} macosx))

unikernel/duniverse/dune_/doc/reference/cli.rst

@@ -0,0 +1,231 @@
+Command Line Interface
+======================
+
+This is a short overview of the commands available in Dune. Reference
+documentation for each command is available through ``dune COMMAND --help``.
+
+.. describe:: dune build
+
+   Build the given targets, or the default ones.
+
+.. describe:: dune cache
+
+   Manage the shared cache of build artifacts.
+
+   .. describe:: dune cache size
+
+      Query the size of the Dune cache.
+
+   .. describe:: dune cache trim
+
+      Trim the Dune cache.
+
+.. describe:: dune clean
+
+   Clean the project.
+
+.. describe:: dune coq
+
+   Command group related to Coq.
+
+   .. describe:: dune coq top
+
+      Execute a Coq toplevel with the local configuration.
+
+.. describe:: dune describe
+
+   Describe the workspace.
+
+   .. describe:: dune describe aliases
+
+      Print aliases in a given directory. Works similarly to ls.
+
+   .. describe:: dune describe env
+
+      Print the environment of a directory.
+
+   .. describe:: dune describe external-lib-deps
+
+      Print out the external libraries needed to build the project. It's an
+      approximated set of libraries.
+
+   .. describe:: dune describe installed-libraries
+
+      Print out the libraries installed on the system.
+
+   .. describe:: dune describe opam-files
+
+      Print information about the opam files that have been discovered.
+
+   .. describe:: dune describe package-entries
+
+      prints information about the entries per package.
+
+   .. describe:: dune describe pp
+
+      Build a given file and print the preprocessed output.
+
+   .. describe:: dune describe rules
+
+      Dump rules.
+
+   .. describe:: dune describe targets
+
+      Print targets in a given directory. Works similarly to ls.
+
+   .. describe:: dune describe workspace
+
+      Print a description of the workspace's structure. If some directories
+      are provided, then only those directories of the workspace are
+      considered.
+
+.. describe:: dune diagnostics
+
+   Fetch and return errors from the current build.
+
+.. describe:: dune exec
+
+   Execute a command in a similar environment as if installation was performed.
+
+.. describe:: dune fmt
+
+   Format source code.
+
+.. describe:: dune format-dune-file
+
+   Format ``dune`` files.
+
+.. describe:: dune help
+
+   Additional Dune help.
+
+.. describe:: dune init
+
+   Command group for initializing Dune components.
+
+   .. describe:: dune init executable
+
+      Initialize a binary executable.
+
+   .. describe:: dune init library
+
+      Initialize an OCaml library.
+
+   .. describe:: dune init project
+
+      Initialize a whole OCaml project.
+
+   .. describe:: dune init test
+
+      Initialize a test harness.
+
+.. describe:: dune install
+
+   Install packages defined in workspace.
+
+.. describe:: dune installed-libraries
+
+   Print out libraries installed on the system.
+
+.. describe:: dune ocaml
+
+   Command group related to OCaml.
+
+   .. describe:: dune ocaml dump-dot-merlin
+
+      Print Merlin configuration.
+
+   .. describe:: dune ocaml merlin
+
+      Command group related to Merlin.
+
+      .. describe:: dune ocaml merlin dump-config
+
+         Prints the entire content of the Merlin configuration for the given
+         folder in a user friendly form.
+
+      .. describe:: dune ocaml merlin start-session
+
+         Start a Merlin configuration server.
+
+   .. describe:: dune ocaml ocaml-merlin
+
+      Start a Merlin configuration server.
+
+   .. describe:: dune ocaml top
+
+      Print a list of toplevel directives for including directories and loading
+      ``.cma`` files.
+
+   .. describe:: dune ocaml top-module
+
+      Print a list of toplevel directives for loading a module into the toplevel.
+
+   .. describe:: dune ocaml utop
+
+      Load library in UTop.
+
+.. describe:: dune ocaml-merlin
+
+   Start a Merlin configuration server.
+
+.. describe:: dune printenv
+
+   Print the environment of a directory.
+
+.. describe:: dune promotion
+
+   Control how changes are propagated back to source code.
+
+   .. describe:: dune promotion apply
+
+           Promote files from the last run.
+
+   .. describe:: dune promotion diff
+
+           List promotions to be applied.
+
+.. describe:: dune promote
+
+   A command alias for ``dune promotion apply``.
+
+.. describe:: dune rpc
+
+   Dune's RPC mechanism. Experimental.
+
+.. describe:: dune rules
+
+   Dump rules.
+
+.. describe:: dune runtest
+
+   Run tests.
+
+.. describe:: dune test
+
+   A command alias for ``dune runtest``.
+
+.. describe:: dune shutdown
+
+   Cancel and shutdown any builds in the current workspace.
+
+.. describe:: dune subst
+
+   Substitute watermarks in source files.
+
+.. describe:: dune top
+
+   Print a list of toplevel directives for including directories and loading
+   ``.cma`` files.
+
+.. describe:: dune uninstall
+
+   Uninstall packages defined in the workspace.
+
+.. describe:: dune upgrade
+
+   Upgrade projects across major Dune versions.
+
+.. describe:: dune utop
+
+   Load library in UTop.

unikernel/duniverse/dune_/doc/reference/config/action_stderr_on_success.rst

@@ -0,0 +1,5 @@
+action_stderr_on_success
+------------------------
+
+Same as :doc:`action_stdout_on_success`, but applies to standard error instead
+of standard output.

unikernel/duniverse/dune_/doc/reference/config/action_stdout_on_success.rst

@@ -0,0 +1,17 @@
+action_stdout_on_success
+------------------------
+
+Specifies how Dune should handle the standard output of actions when they succeed.
+This can be used to reduce the noise of large builds.
+
+.. code:: dune
+
+    (action_stdout_on_success <setting>)
+
+where ``<setting>`` is one of:
+
+- ``print`` prints the output on the terminal. This is the default.
+
+- ``swallow`` ignores the output and does not print it on the terminal.
+
+- ``must-be-empty`` enforces that the output should be empty. If it is not, Dune will fail.

unikernel/duniverse/dune_/doc/reference/config/cache.rst

@@ -0,0 +1,19 @@
+cache
+-----
+
+Specifies whether Dune is allowed to store and fetch build targets from the Dune
+cache.
+
+.. code:: dune
+
+    (cache <setting>)
+
+where ``<setting>`` is one of:
+
+- ``enabled`` enables Dune cache.
+
+- ``enabled-except-user-rules`` enables the Dune cache, but exclude user-written
+  rules. This setting is a conservative choice that can avoid breaking rules
+  whose dependencies are not correctly specified. Currently the default.
+
+- ``disabled`` disables Dune cache.

unikernel/duniverse/dune_/doc/reference/config/cache_check_probability.rst

@@ -0,0 +1,16 @@
+cache-check-probability
+-----------------------
+
+While the main purpose of Dune cache is to speed up build times, it can also be
+used to check build reproducibility. It is possible to enable a probabilistic
+check, in which Dune will re-execute randomly chosen build rules and compare
+their results with those stored in the cache. If the results differ, the rule is
+not reproducible, and Dune will print out a corresponding warning.
+
+.. code:: dune
+
+    (cache-check-probability <number>)
+
+where ``<number>`` is a floating-point number between 0 and 1 (inclusive). 0
+means never to check for reproducibility, and 1 means to always perform the
+check.

unikernel/duniverse/dune_/doc/reference/config/cache_storage_mode.rst

@@ -0,0 +1,19 @@
+cache-storage-mode
+------------------
+
+Specify the mechanism used by the Dune cache for storage.
+
+.. code:: dune
+
+    (cache-storage-mode <setting>)
+
+where ``<setting>`` is one of:
+
+- ``auto`` lets Dune decide the best mechanism to use.
+
+- ``hardlink`` uses hard links for entries in the cache. If the cache is stored
+  in a different partition than the one where the build is taking place, then
+  this mode will not work and ``copy`` should be used instead.
+
+- ``copy`` copies entries to the cache. This is less efficient than using hard
+  links.

unikernel/duniverse/dune_/doc/reference/config/display.rst

@@ -0,0 +1,21 @@
+display
+-------
+
+Specify the amount of Dune’s verbosity.
+
+.. code:: dune
+
+    (display <setting>)
+
+where ``<setting>`` is one of:
+
+- ``progress``, Dune shows and updates a status line as build goals are being
+  completed. This is the default value.
+
+- ``verbose`` prints the full command lines of programs being executed by Dune,
+  with some colors to help differentiate programs.
+
+- ``short`` prints a line for each program executed with the binary name on the
+  left and the targets of the action on the right.
+
+- ``quiet`` only display errors.

unikernel/duniverse/dune_/doc/reference/config/index.rst

@@ -0,0 +1,27 @@
+config
+======
+
+This file is used to set Dune's global configuration, which is applicable
+across projects and workspaces.
+
+The configuration file is normally ``~/.config/dune/config`` on Unix systems
+and ``%LOCALAPPDATA%/dune/config`` on Windows. However, for most Dune commands,
+it is possible to specify an alternative configuration file with the
+``--config-file`` option. Command-line flags take precedence over the contents
+of the ``config`` file.  If ``--no-config`` or ``-p`` is passed, Dune will not
+read this file.
+
+The ``config`` file can contain the following stanzas:
+
+.. toctree::
+
+  action_stdout_on_success
+  action_stderr_on_success
+  cache
+  cache_check_probability
+  cache_storage_mode
+  display
+  jobs
+  project_defaults
+  sandboxing_preference
+  terminal_persistence

unikernel/duniverse/dune_/doc/reference/config/jobs.rst

@@ -0,0 +1,15 @@
+jobs
+----
+
+Maximum number of concurrent jobs Dune is allowed to have.
+
+.. code:: dune
+
+    (jobs <setting>)
+
+where ``<setting>`` is one of:
+
+- ``auto``, auto-detect maximum number of cores. This is the default value.
+
+- ``<number>``, a positive integer specifying the maximum number of jobs Dune
+  may use simultaneously.

unikernel/duniverse/dune_/doc/reference/config/project_defaults.rst

@@ -0,0 +1,53 @@
+project_defaults
+----------------
+
+.. versionadded:: 3.17
+
+Specify default values for stanzas ``authors``, ``maintainers``, and ``license``
+of the :doc:`../dune-project/index` file when initializing a project with 
+``dune init proj``. The format of the 'project_defaults' stanza is as follows:
+
+.. code:: dune
+
+   (project_defaults
+    <optional-fields>)
+
+``<optional-fields>`` are:
+
+.. describe:: (authors <string(s)>)
+
+   Specify authors.
+
+   Example:
+
+   .. code:: dune
+        
+       (project_defaults
+        (authors
+         "Jane Doe <jane.doe@example.com>"
+         "John Doe <john.doe@example.com>"))
+
+.. describe:: (maintainers <string(s)>)
+
+   Specify maintainers.
+
+   Example:
+
+   .. code:: dune
+
+       (project_defaults
+        (maintainers
+         "Jane Doe <jane.doe@example.com>"
+         "John Doe <john.doe@example.com>"))
+
+.. describe:: (license <string(s)>)
+
+   Specify license, ideally as an identifier from the `SPDX License List
+   <https://spdx.org/licenses/>`__.
+
+   Example:
+
+   .. code:: dune
+
+       (project_defaults
+        (license "MIT"))

unikernel/duniverse/dune_/doc/reference/config/sandboxing_preference.rst

@@ -0,0 +1,19 @@
+sandboxing_preference
+---------------------
+
+The preferred sandboxing setting. Individual rules may specify different
+preferences. Dune will try to utilize a setting satisfying both conditions.
+
+.. code:: dune
+
+    (sandboxing_preference <setting> <setting> ...)
+
+where each ``<setting>`` can be one of:
+
+- ``none`` disables sandboxing.
+
+- ``hardlink`` uses hard links for sandboxing. This is the default under Linux.
+
+- ``copy`` copies files for sandboxing. This is the default under Windows.
+
+- ``symlink`` uses symbolic links for sandboxing.

unikernel/duniverse/dune_/doc/reference/config/terminal_persistence.rst

@@ -0,0 +1,17 @@
+terminal-persistence
+--------------------
+
+Specifies how Dune handles the terminal when a rebuild is triggered in watch mode.
+
+.. code:: dune
+
+    (terminal-persistence <setting>)
+
+where ``<setting>`` is one of:
+
+- ``preserve`` does not clear the terminal screen between rebuilds.
+
+- ``clear-on-rebuild`` clears the terminal screen between rebuilds.
+
+- ``clear-on-rebuild-and-flush-history`` clears the terminal between rebuilds, and
+  it also deletes everything in the scrollback buffer.

unikernel/duniverse/dune_/doc/reference/cram.rst

@@ -0,0 +1,205 @@
+Cram Tests
+==========
+
+Synopsis
+--------
+
+Cram tests are integrations tests that describe a shell session. These tests
+contain commands and expected outputs. When executed, the commands are executed
+and the actual output is compared to the expected output.
+
+Here is an example showing how ``echo``, ``cat``, and ``rm`` interact.
+
+.. code:: cram
+
+   Create a file:
+
+     $ echo contents > data.txt
+
+   Display it:
+
+     $ cat data.txt
+     contents
+
+   Remove it:
+
+     $ rm data.txt
+
+   Try to remove it again:
+
+     $ rm data.txt
+     rm: cannot remove 'data.txt': No such file or directory
+     [1]
+
+The syntax mimics a shell session: there are comments and shell commands with
+their output.
+
+Examples
+--------
+
+Simple Commands
+^^^^^^^^^^^^^^^
+
+This is the simplest test case: it executes the command ``touch
+this-file.txt`` and expects that the command has no output.
+
+.. code:: console
+
+   $ touch this-file.txt
+
+Output
+^^^^^^
+
+This executes ``ls`` and expects it to display ``this-file.txt``:
+
+.. code:: console
+
+   $ ls
+   this-file.txt
+
+There can be several output lines if the command is expected to print several
+lines.
+Also, note that if a command has no output, the next one can come in the next
+line.
+
+.. code:: console
+
+   $ touch other-file.txt
+   $ ls
+   other-file.txt
+   this-file.txt
+
+Comments
+^^^^^^^^
+
+Lines that are not indented are ignored. These act as comments.
+
+.. code:: cram
+
+   "touch" will create an empty file:
+
+     $ touch data.txt
+
+   Printing it will do nothing:
+
+     $ cat data.txt
+
+Continuation Lines
+^^^^^^^^^^^^^^^^^^
+
+Continuation lines are used when a command fits on several lines. This can
+happen in all the cases where pressing Enter would not run the command. For
+example, when passing a backslash character to escape the line ending. In that
+case, all the continuation lines are grouped together as a single command.
+
+This syntax mimics the PS2 prompt in shells - the ">" character is not passed
+to the command.
+
+.. code:: console
+
+   $ echo \
+   >   a \
+   >   b \
+   >   d \
+   >   c
+   a b c d
+
+This is often used with shell "heredocs" to create files:
+
+.. code:: console
+
+   $ cat > file.txt << EOF
+   > Everything
+   > here will
+   > written to
+   > the file
+   > EOF
+
+   $ cat file.txt
+   Everything
+   here will
+   written to
+   the file
+
+Exit Codes
+^^^^^^^^^^
+
+When a command exits with a nonzero exit code, it is displayed between square
+brackets after its output:
+
+.. code:: console
+
+   $ false
+   [1]
+
+   $ echo hello; false
+   hello
+   [1]
+
+Syntax Details
+--------------
+
+Cram tests are parsed line by line, depending on the first characters of
+each line:
+
+- If a line starts with ``␣␣$␣`` (``␣`` denoting a space character), the rest
+  is a command.
+- If it starts with ``␣␣>␣``, the rest is the continuation of a command
+  (continuation lines must immediately follow a command).
+- If it start with ``␣␣`` and something else, the rest is the expected output
+  or exit code of the previous command.
+- Everything else is a comment.
+
+File and Directory Tests
+------------------------
+
+There are two types of Cram tests: file tests and directory tests. File tests
+are files with a ``.t`` extension. Directory tests are files named ``run.t``
+within a directory with a name that ends with ``.t``.
+
+A Cram test begins its execution in a temporary directory where its
+dependencies (as listed in the corresponding :doc:`cram stanzas <dune/cram>`,
+if any) are available. In the case of a directory test, the contents of the
+directory are also available.
+
+File tests have the nice property that they are self-contained: everything
+happens in a single file. This is handy because it does not make a deep file
+hierarchy in a project. But if the test requires some files, these need to be
+created using ``cat`` and heredocs. Directory tests, on the other hand, allow
+creating these test fixtures as normal files. This can be more comfortable
+because it makes the usual tooling (syntax highlighting, completion, etc.)
+available.
+
+Executing Cram Tests
+--------------------
+
+Every Cram test has a name. For file tests, the name of ``something.t`` is
+``something``, and for directory tests, the name of ``something.t/run.t`` is
+``something``.
+
+There are several ways to execute Cram tests:
+
+- Running ``dune runtest something.t`` will run the cram test with filename
+  ``something.t``.
+- All Cram tests are attached to the :doc:`/reference/aliases/runtest` alias.
+  So ``dune runtest`` will run all Cram tests.
+- Every Cram test creates an alias after its name. So, ``dune build
+  @something`` will run tests named ``something``.
+
+
+When a Cram test is executed, the commands it contains are executed, and a
+corrected file is created where the command outputs are inserted after
+each command. This corrected file is then offered for :doc:`promotion
+<../concepts/promotion>` by Dune.
+
+Concretely, this means that Dune will display the difference between the
+Cram test's current contents and the latest run's output. This diff
+can be applied by running ``dune promote``, as usual.
+
+.. code:: diff
+
+   $ touch changed-name.txt
+   $ ls
+  -other-file.txt
+  +changed-name.txt
+   this-file.txt

unikernel/duniverse/dune_/doc/reference/dune-project/accept_alternative_dune_file_name.rst

@@ -0,0 +1,17 @@
+accept_alternative_dune_file_name
+---------------------------------
+
+.. describe:: (accept_alternative_dune_file_name ...)
+
+   .. versionadded:: 3.0
+
+   Specify that the alternative filename ``dune-file`` is accepted in addition
+   to ``dune``.
+
+   This may be useful to avoid problems with ``dune`` files that have the
+   executable permission in a directory in the ``PATH``, which can unwittingly
+   happen on Windows.
+
+   Note that ``dune`` continues to be accepted even after enabling this option,
+   but if a file named ``dune-file`` is found in a directory, it will take
+   precedence over ``dune``.

unikernel/duniverse/dune_/doc/reference/dune-project/authors.rst

@@ -0,0 +1,19 @@
+authors
+-------
+
+.. describe:: (authors <strings>)
+
+   .. versionadded:: 1.9
+
+   Specify authors.
+
+   Valid for all packages defined in the current Dune project. May be overriden
+   by the per-package field (see :doc:`package`).
+
+   Example:
+
+   .. code:: dune
+
+      (authors
+       "Jane Doe <jane.doe@example.com>"
+       "John Doe <john.doe@example.com>")

unikernel/duniverse/dune_/doc/reference/dune-project/bug_reports.rst

@@ -0,0 +1,19 @@
+bug_reports
+-----------
+
+.. describe:: (bug_reports <url>)
+
+   .. versionadded:: 1.10
+
+   Where bugs should be reported.
+
+   If a hosting service is used in ``(source)``, a default value is provided.
+
+   Valid for all packages defined in the current Dune project. May be overriden
+   by the per-package field (see :doc:`package`).
+
+   Example:
+
+   .. code:: dune
+
+      (bug_reports https://dev.example.com/project/issues)

unikernel/duniverse/dune_/doc/reference/dune-project/cram.rst

@@ -0,0 +1,11 @@
+cram
+----
+
+.. describe:: (cram <status>)
+
+   Define whether Cram-style tests are enabled for the project.
+
+   `<status>` can be either ``enable`` or ``disable``. The default is
+   ``enable`` starting from the language version 3.0.
+
+   .. seealso:: :ref:`cram-tests`

unikernel/duniverse/dune_/doc/reference/dune-project/dialect.rst

@@ -0,0 +1,93 @@
+dialect
+-------
+
+.. describe:: (dialect ...)
+
+   Declare a new :term:`dialect`.
+
+   .. describe:: (name <name>)
+
+      The name of the dialect being defined. It must be unique in a given
+      project.
+
+      This field is required.
+
+   .. describe:: (implementation ...)
+
+      Details related to the implementation files (corresponding to `*.ml`).
+
+      .. versionchanged:: 3.9 This field is made optional.
+
+      .. describe:: (extension <string>)
+
+         Specify the file extension used for this dialect.
+
+         The extension string must not start with a period and be unique in a
+         given project (so that a given extension can be mapped back to a
+         corresponding dialect). In Dune 3.9 and later, the extension string may
+         contain periods (e.g., `cppo.ml`).
+
+         This field is required.
+
+      .. describe:: (preprocess <action>)
+
+         Run `<action>` to produce a valid OCaml abstract syntax tree.
+
+         This action is expected to read the file given in the variable named
+         ``%{input-file}`` and output a *binary* abstract syntax tree on its
+         standard output.
+
+         If the field is not present, it is assumed that the corresponding
+         source code is already valid OCaml code and can be passed to the OCaml
+         compiler as-is.
+
+         .. seealso:: :ref:`preprocessing-actions`
+
+      .. describe:: (format <action>)
+
+         Run `<action>` to format source code for this dialect.
+
+         The action is expected to read the file given in the variable named
+         ``%{input-file}`` and output the formatted source code on its standard
+         output.
+
+         If the field is not present, the behavior depends on the presence of
+         ``(preprocess)``: if it is also not present (that is, the dialect
+         consists of valid OCaml code), then the dialect will be formatted as
+         any other OCaml code. Otherwise no special formatting will be done.
+
+         .. seealso:: :doc:`/howto/formatting`
+
+   .. describe:: (interface ...)
+
+      Details related to the interface files (corresponding to `*.mli`).
+
+      This field supports the same sub-fields as ``implementation``.
+
+      .. versionchanged:: 3.9 This field is made optional.
+
+   .. describe:: (merlin_reader <program> <args>...)
+
+      Configure Merlin to use `<program> <args>...` as READER. Merlin's READER
+      is a mechanism to extend Merlin to support OCaml dialects by providing
+      a program that transforms a dialect AST into an OCaml AST.
+
+      .. seealso:: `merlin/src/extend/extend_protocol.ml <https://github.com/ocaml/merlin/blob/4.14-502_preview2/src/extend/extend_protocol.ml>`_ for the protocol specification.
+
+      This field is optional.
+
+      .. versionadded:: 3.16
+
+
+Default dialects
+----------------
+
+Dune ships with two dialects pre-configured and enabled:
+
+* ``ocaml`` for the default OCaml syntax which consumes `.ml` and `.mli` files
+  and uses ``ocamlformat`` for formatting.
+* ``reason`` for the Reason syntax and enabled in `.re`/`.rei` files. ``refmt``
+  is used for formatting.
+
+A third dialect, ``rescript``, is added when Melange support (see :doc:`/melange`)
+is enabled in the project.

unikernel/duniverse/dune_/doc/reference/dune-project/documentation.rst

@@ -0,0 +1,11 @@
+documentation
+-------------
+
+.. describe:: (documentation <url>)
+
+   .. versionadded:: 1.10
+
+   Where the documentation is hosted.
+
+   Valid for all packages in the current Dune project. May be overriden by the
+   per-package field (see :doc:`package`).

unikernel/duniverse/dune_/doc/reference/dune-project/executables_implicit_empty_intf.rst

@@ -0,0 +1,25 @@
+executables_implicit_empty_intf
+-------------------------------
+
+.. describe:: (executables_implicit_empty_intf ...)
+
+   .. versionadded:: 2.9
+
+   Automatically generate empty interface files for executables and tests that
+   do not already have them.
+
+   By default, executables defined via ``(executables(s) ...)`` or ``(test(s)
+   ...)`` stanzas are compiled with the interface file provided (e.g., ``.mli``
+   or ``rei``). Since these modules cannot be used as library dependencies,
+   it is common to give them empty interface files to strengthen the compiler's
+   ability to detect unused values in these modules.
+
+   This option, when enabled, will generate an empty `*.mli` file.
+
+   Example:
+
+   .. code:: dune
+
+       (executables_implicit_empty_intf true)
+
+   This option is enabled by default starting with Dune lang 3.0.

unikernel/duniverse/dune_/doc/reference/dune-project/expand_aliases_in_sandbox.rst

@@ -0,0 +1,21 @@
+expand_aliases_in_sandbox
+-------------------------
+
+.. describe:: (expand_aliases_in_sandbox ...)
+
+   When a sandboxed action depends on an alias, copy the expansion of the alias
+   inside the sandbox. For instance, in the following example:
+
+   .. code:: dune
+
+      (alias
+       (name foo)
+       (deps ../x))
+
+      (cram
+       (deps (alias foo)))
+
+   File `x` will be visible inside the Cram test if and only if this option is
+   enabled. This option is a better default in general; however, it currently
+   causes Cram tests to run noticeably slower. So it is disabled by default
+   until the performance issue with Cram test is fixed.

unikernel/duniverse/dune_/doc/reference/dune-project/explicit_js_mode.rst

@@ -0,0 +1,24 @@
+explicit_js_mode
+----------------
+
+.. describe:: (explicit_js_mode ...)
+
+   Do not implicitly add ``js`` to the ``(modes ...)`` field of executables.
+
+   In projects that use dune lang 1.x, JavaScript targets are defined for every
+   bytecode executable. This is not very precise and does not interact well
+   with the :doc:`/reference/aliases/all` alias.
+
+   It is possible to opt out of this behavior by using:
+
+   .. code:: dune
+
+       (explicit_js_mode)
+
+   When this is enabled, an explicit ``js`` mode needs to be added to the
+   ``(modes ...)`` field of executables in order to trigger the JavaScript
+   compilation. Explicit JS targets declared like this will be attached to the
+   :doc:`/reference/aliases/all` alias.
+
+   Starting with Dune 2.0, this behavior is the default, and there is no way to
+   disable it.

unikernel/duniverse/dune_/doc/reference/dune-project/formatting.rst

@@ -0,0 +1,27 @@
+formatting
+----------
+
+.. describe:: (formatting ...)
+
+   .. versionadded:: 2.0
+
+   Control automatic formatting. Several forms are accepted:
+
+   - To disable automatic formatting completely (equivalent to the behavior in
+     language 1.x):
+
+     .. code:: dune
+
+        (formatting disabled)
+
+   - To restrict the languages that are considered for formatting:
+
+     .. code:: dune
+
+        (formatting
+         (enabled_for <languages>))
+
+     The list of `<languages>` can be either ``dune`` (formatting of ``dune``
+     files) or a :term:`dialect` name.
+
+   .. seealso:: :doc:`/howto/formatting`

unikernel/duniverse/dune_/doc/reference/dune-project/generate_opam_files.rst

@@ -0,0 +1,22 @@
+generate_opam_files
+-------------------
+
+.. describe:: (generate_opam_files ...)
+
+   .. versionadded:: 1.10
+
+   Use metadata specified in the ``dune-project`` file to generate ``.opam``
+   files.
+
+   To enable this integration, add the following field to the ``dune-project``
+   file:
+
+   .. code:: dune
+
+      (generate_opam_files)
+
+   .. seealso:: :doc:`/howto/opam-file-generation`
+
+With this field, every time one calls Dune to execute some rules (either via
+``dune build``, ``dune runtest``, or something else), the opam files get
+generated.

unikernel/duniverse/dune_/doc/reference/dune-project/homepage.rst

@@ -0,0 +1,19 @@
+homepage
+--------
+
+.. describe:: (homepage <url>)
+
+   .. versionadded:: 1.10
+
+   The homepage of the project.
+
+   If a hosting service is used in ``(source)``, a default value is provided.
+
+   Valid for all packages defined in the current Dune project. May be overriden
+   by the per-package field (see :doc:`package`).
+
+   Example:
+
+   .. code:: dune
+
+      (bug_reports https://example.com/)

unikernel/duniverse/dune_/doc/reference/dune-project/implicit_transitive_deps.rst

@@ -0,0 +1,47 @@
+implicit_transitive_deps
+------------------------
+
+.. describe:: (implicit_transitive_deps <setting>)
+
+   Control whether transitive dependencies are made implicitly visible during
+   compilation.
+
+   ``<setting>`` is one of:
+
+   - ``true`` makes transitive dependencies implicitly visible. This is the
+     default.
+
+   - ``false`` only listed dependencies are visible. If the ``-H`` flag is
+     supported by the compiler (OCaml version >= 5.2) and Dune language version
+     is >= 1.17, Dune will pass the flag to the compiler, which avoids some
+     corner cases (see below).
+
+   - ``false-if-hidden-includes-supported`` only listed dependencies are visible
+     if the compiler supports the ``-H`` flag. Otherwise (OCaml version < 5.2),
+     the setting is ignored and all transitive dependencies are made visible.
+     Introduced in Dune 3.20.
+
+   .. code:: dune
+
+       (implicit_transitive_deps false)
+
+   Then all dependencies directly used by a library or an executable must be
+   added in the ``libraries`` field.
+
+   We recommend users experiment with this mode and report any problems.
+
+   Note that if ``-H`` flag is not being used, you must use ``threads.posix``
+   instead of ``threads`` when using this mode. This isn't an important
+   limitation, as ``threads.vm`` is deprecated anyway.
+
+   In some situations, it can be desirable to selectively preserve the behavior
+   of transitive dependencies' availability a library's users. For example, if
+   we define a library ``foo_more`` that extends ``foo``, we might want
+   ``foo_more`` users to immediately have ``foo`` available as well. To do
+   this, we must define the dependency on ``foo`` as re-exported:
+
+   .. code:: dune
+
+      (library
+       (name foo_more)
+       (libraries (re_export foo)))

unikernel/duniverse/dune_/doc/reference/dune-project/index.rst

@@ -0,0 +1,47 @@
+dune-project
+============
+
+Each ``dune-project`` file marks the root of a Dune projects within the current
+Dune workspace (see :doc:`/explanation/scopes`). It can also specify project-wide
+parameters.
+
+The first line of ``dune-project`` must be a ``lang`` stanza with no extra
+whitespace or comments. The ``lang`` stanza controls the names and contents of
+all configuration files read by Dune and looks like:
+
+.. code:: dune
+
+   (lang dune 3.14)
+
+Additionally, they can contains the following stanzas.
+
+.. toctree::
+
+  accept_alternative_dune_file_name
+  authors
+  bug_reports
+  cram
+  dialect
+  documentation
+  executables_implicit_empty_intf
+  expand_aliases_in_sandbox
+  explicit_js_mode
+  formatting
+  generate_opam_files
+  homepage
+  implicit_transitive_deps
+  license
+  maintainers
+  maintenance_intent
+  map_workspace_root
+  name
+  opam_file_location
+  package
+  pin
+  source
+  subst
+  use_standard_c_and_cxx_flags
+  using
+  version
+  warnings
+  wrapped_executables

unikernel/duniverse/dune_/doc/reference/dune-project/license.rst

@@ -0,0 +1,20 @@
+license
+-------
+
+.. describe:: (license <strings>)
+
+   .. versionadded:: 1.9
+
+   Specify the license of the project, ideally as an identifier from the `SPDX
+   License List <https://spdx.org/licenses/>`__.
+
+   Valid for all packages defined in the current Dune project. May be overriden
+   by the per-package field (see :doc:`package`).
+
+   Example:
+
+   .. code:: dune
+
+      (license MIT)
+
+   Multiple licenses may be specified.

unikernel/duniverse/dune_/doc/reference/dune-project/maintainers.rst

@@ -0,0 +1,19 @@
+maintainers
+-----------
+
+.. describe:: (maintainers <strings>)
+
+   .. versionadded:: 1.10
+
+   Specify maintainers.
+
+   Valid for all packages defined in the current Dune project. May be overriden
+   by the per-package field (see :doc:`package`).
+
+   Example:
+
+   .. code:: dune
+
+      (maintainers
+       "Jane Doe <jane.doe@example.com>"
+       "John Doe <john.doe@example.com>")

unikernel/duniverse/dune_/doc/reference/dune-project/maintenance_intent.rst

@@ -0,0 +1,18 @@
+maintenance_intent
+------------------
+
+.. _maintenance_intent:
+.. describe:: (maintenance_intent <strings>)
+
+   .. versionadded:: 3.18
+
+   Specify the `opam maintenance intent <https://github.com/ocaml/opam-repository/blob/master/governance/policies/archiving.md#specification-of-the-x--fields-used-in-the-archiving-process>`__.
+
+   Valid for all packages defined in the current Dune project. May be overriden
+   by the per-package field (see :doc:`package`).
+
+   Example:
+
+   .. code:: dune
+
+      (maintenance_intent "(latest)")

unikernel/duniverse/dune_/doc/reference/dune-project/map_workspace_root.rst

@@ -0,0 +1,21 @@
+map_workspace_root
+-------------------
+
+.. describe:: (map_workspace_root <bool>)
+
+   Control references to the file system locations where the project has been
+   built.
+
+   - with ``(map_workspace_root true)``, dune rewrites references to the
+     workspace root to ``/workspace_root``. Note that when this mapping is
+     enabled, the debug information produced by the bytecode compiler is
+     incorrect, as the location information is lost.
+
+   - with ``(map_workspace_root false)``, the references are not rewritten.
+
+   The default is ``(map_workspace_root true)``.
+
+   .. versionadded:: 3.0
+        Initial version with the mapping always enabled.
+   .. versionchanged:: 3.7
+        Add a way to disable the mapping.

unikernel/duniverse/dune_/doc/reference/dune-project/name.rst

@@ -0,0 +1,8 @@
+name
+----
+
+.. describe:: (name <string>)
+
+   Set the name of the project.
+
+   It is used by :ref:`dune subst <dune-subst>` and error messages.

unikernel/duniverse/dune_/doc/reference/dune-project/opam_file_location.rst

@@ -0,0 +1,17 @@
+opam_file_location
+------------------
+
+.. describe:: (opam_file_location <location>)
+
+   .. versionadded:: 3.8
+
+   Configure where generated ``.opam`` files are located. `<location>` can
+   be one of the following:
+
+   - ``relative_to_project``: the ``.opam`` files are generated in the project
+     root directory. This is the default.
+
+   - ``inside_opam_directory``: the ``.opam`` files are generated in a directory
+     named ``opam`` in the project root directory.
+
+   .. seealso:: :doc:`/howto/opam-file-generation`

unikernel/duniverse/dune_/doc/reference/dune-project/package.rst

@@ -0,0 +1,135 @@
+package
+-------
+
+This stanza is used to specify package metadata. In particular, this information
+is used when generating OPAM files (see :doc:`generate_opam_files`).
+
+.. describe:: (package ...)
+
+   Define package-specific metadata.
+
+   .. describe:: (name <string>)
+
+      The name of the package.
+
+      This must be specified.
+
+   .. describe:: (synopsis <string>)
+
+      A short package description.
+
+   .. describe:: (description <string>)
+
+      A longer package description.
+
+   .. describe:: (depends <dep-specification>)
+
+      Package dependencies, as :token:`~pkg-dep:dep_specification`.
+
+   .. describe:: (conflicts <dep-specification>)
+
+      Package conflicts, as :token:`~pkg-dep:dep_specification`.
+
+   .. describe:: (depopts <dep-specification>)
+
+      Optional package dependencies, as :token:`~pkg-dep:dep_specification`.
+
+   .. describe:: (tags <tags>)
+
+      A list of tags.
+
+   .. describe:: (deprecated_package_names <name list>)
+
+      A list of names that can be used with the
+      :doc:`../dune/deprecated_library_name` stanza to migrate legacy libraries
+      from other build systems that do not follow Dune's convention of
+      prefixing the library's public name with the package name.
+
+   .. describe:: (license ...)
+
+      .. versionadded:: 2.0
+
+      The same as (and takes precedences over) the corresponding global field
+      (see :doc:`license`).
+
+   .. describe:: (authors ...)
+
+      .. versionadded:: 2.0
+
+      The same as (and takes precedences over) the corresponding global field
+      (see :doc:`authors`).
+
+   .. describe:: (maintainers ...)
+
+      .. versionadded:: 2.0
+
+      The same as (and takes precedences over) the corresponding global field
+      (see :doc:`maintainers`).
+
+   .. describe:: (maintenance_intent ...)
+
+      .. versionadded:: 3.18
+
+      The same as (and takes precedences over) the corresponding global field
+      (see :doc:`maintenance_intent`).
+
+   .. describe:: (source ...)
+
+      .. versionadded:: 2.0
+
+      The same as (and takes precedences over) the corresponding global field
+      (see :doc:`source`).
+
+   .. describe:: (bug_reports ...)
+
+      .. versionadded:: 2.0
+
+      The same as (and takes precedences over) the corresponding global field
+      (see :doc:`bug_reports`).
+
+   .. describe:: (homepage ...)
+
+      .. versionadded:: 2.0
+
+      The same as (and takes precedences over) the corresponding global field
+      (see :doc:`homepage`).
+
+   .. describe:: (documentation ...)
+
+      .. versionadded:: 2.0
+
+      The same as (and takes precedences over) the corresponding global field
+      (see :doc:`documentation`).
+
+   .. describe:: (sites ...)
+
+      Define a site.
+
+      ``(sites (<section> <name>) ...)`` defines a site named ``<name>`` in the
+      section ``<section>``.
+
+Adding libraries to different packages is done via the ``public_name`` and
+``package`` fields. See :doc:`../dune/library` section for details.
+
+The list of dependencies :token:`~pkg-dep:dep_specification` is modelled after
+opam's own language. The syntax is a list of the following elements:
+
+.. productionlist:: pkg-dep
+   op : '=' | '<' | '>' | '<>' | '>=' | '<='
+   filter : :dev | :build | :with-test | :with-doc | :with-dev-setup | :post
+   constr : (<op> <version>)
+   logop : or | and
+   dep : <name>
+       : (<name> <filter>)
+       : (<name> <constr>)
+       : (<name> (<logop> (<filter> | <constr>))*)
+   dep_specification : <dep>+
+
+Filters will expand to any opam variable name if prefixed by ``:``, not just the
+ones listed in :token:`~pkg-dep:filter`. This also applies to version numbers.
+For example, to generate ``depends: [ pkg { = version } ]``, use ``(depends
+(pkg (= :version)))``.
+
+Note that the use of a ``using`` stanza (see :doc:`using`) doesn't
+automatically add the associated library or tool as a dependency. They have to
+be added explicitly.

unikernel/duniverse/dune_/doc/reference/dune-project/pin.rst

@@ -0,0 +1,50 @@
+pin
+---
+
+.. warning::
+
+   :doc:`Dune Package Management </explanation/package-management>` is not
+   final yet and the configuration options are subject to change.
+
+Pins are package overrides used in the context of package management. They
+allow to fix a package at a specific version which is not affected by the
+package repositories selected.
+
+.. describe:: (pin ...)
+
+   .. versionadded:: 3.14
+
+   Define a package override.
+
+   .. describe:: (url <string>)
+
+      The URL of the package source.
+
+      This can be a path to a directory on the local file system or remote Git
+      repository. Local paths can be absolute or relative, and may optionally
+      begin with ``file://`` though this is not necessary. Remote Git
+      repository URLs must begin with ``git+``, for example
+      ``git+https://github.com/user/repo`` or
+      ``git+git@github.com:user/repo.git``.
+
+      This must be specified.
+
+   .. describe:: (package ...)
+
+      Defines which package is to be pinned.
+
+      This must be specified.
+
+      .. describe:: (name <string>)
+
+         The name of the package.
+
+         This must be specified.
+
+      .. describe:: (version <string>)
+
+         The version that the package should be assumed to be. Defaults to
+         ``dev`` if unspecified.
+
+.. seealso:: :doc:`pin stanza in dune-workspace </reference/dune-workspace/pin>` for
+   workspace-wide pinning.

unikernel/duniverse/dune_/doc/reference/dune-project/source.rst

@@ -0,0 +1,42 @@
+source
+------
+
+.. describe:: (source ...)
+
+   .. versionadded:: 1.7
+
+   Specify where the source for the package can be found.
+
+   It can be specified as ``(uri <uri>)`` or using shortcuts for some
+   hosting services:
+
+   Valid for all packages defined in the current Dune project. May be overriden
+   by the per-package field (see :doc:`package`).
+
+   .. list-table::
+
+     * - Service
+       - Syntax
+     * - `Github <https://github.com>`_
+       - ``(github user/repo)``
+     * - `Bitbucket <https://bitbucket.org>`_
+       - ``(bitbucket user/repo)``
+     * - `Gitlab <https://gitlab.com>`_
+       - | ``(gitlab user/repo)``
+         | ``(gitlab organization/project/repo)`` *(New in 3.17)*
+     * - `Sourcehut <https://sr.ht>`_
+       - ``(sourcehut user/repo)``
+     * - `Codeberg <https://codeberg.org>`_
+       - ``(codeberg user/repo)`` *(New in 3.17)*
+
+   Examples:
+
+   .. code:: dune
+
+      (source
+       (github ocaml/dune))
+
+   .. code:: dune
+
+      (source
+       (uri https://dev.example.com/project.git))

unikernel/duniverse/dune_/doc/reference/dune-project/subst.rst

@@ -0,0 +1,13 @@
+subst
+-----
+
+.. describe:: (subst <bool>)
+
+   .. versionadded:: 3.0
+
+   Control whether :ref:`dune-subst` is enabled for this project.
+
+   - ``(subst disabled)``, means that any call of ``dune subst`` in this
+     project is forbidden and will result in an error. This line will be
+     omitted from the build instructions when generating opam files.
+   - ``(subst enabled)`` allows substitutions explicitly. This is the default.

unikernel/duniverse/dune_/doc/reference/dune-project/use_standard_c_and_cxx_flags.rst

@@ -0,0 +1,26 @@
+use_standard_c_and_cxx_flags
+----------------------------
+
+.. describe:: (use_standard_c_and_cxx_flags ...)
+
+   .. versionadded:: 2.8
+
+   Control how flags coming from ``ocamlc -config`` are passed to the C
+   compiler command line.
+
+   Historically, they have been systematically prepended without a way to
+   override them.
+
+   If the following is passed, the mechanism is slightly altered:
+
+   .. code:: dune
+
+       (use_standard_c_and_cxx_flags)
+
+   In this mode, Dune will populate the ``:standard`` set of C flags with the
+   content of ``ocamlc_cflags`` and  ``ocamlc_cppflags``. These flags can be
+   completed or overridden using the :doc:`/reference/ordered-set-language`.
+
+   This is the default in the language version 3.0.
+
+   .. seealso:: :doc:`/reference/foreign-flags`

unikernel/duniverse/dune_/doc/reference/dune-project/using.rst

@@ -0,0 +1,21 @@
+using
+-----
+
+.. describe:: (using <plugin> <version>)
+
+   Enable a dune language extension.
+
+   The language of configuration files read by Dune can be extended to support
+   additional stanzas (e.g., ``menhir``, ``coq.theory``, ``mdx``).
+
+   `<plugin>` is the name of the plugin that defines this stanza and
+   `<version>` describes the configuration language's version. Note that this
+   version has nothing to do with the version of the associated tool or
+   library. In particular, adding a ``using`` stanza will not result in a build
+   dependency in the generated ``.opam`` file. See :doc:`generate_opam_files`.
+
+   Example:
+
+   .. code:: dune
+
+      (using mdx 0.3)

unikernel/duniverse/dune_/doc/reference/dune-project/version.rst

@@ -0,0 +1,12 @@
+version
+-------
+
+.. describe:: (version <version>)
+
+   Set the version of the project.
+
+   Example:
+
+   .. code:: dune
+
+      (version 1.2.3)

unikernel/duniverse/dune_/doc/reference/dune-project/warnings.rst

@@ -0,0 +1,12 @@
+warnings
+--------
+
+.. describe:: (warnings ...)
+
+   .. versionadded:: 3.11
+
+   Configure Dune warnings for the project.
+
+   .. describe:: (<name> <enabled | disabled>)
+
+      Enable or disable the warning <name> for the current project.

unikernel/duniverse/dune_/doc/reference/dune-project/wrapped_executables.rst

@@ -0,0 +1,19 @@
+wrapped_executables
+-------------------
+
+.. describe:: (wrapped_executables <bool>)
+
+   .. versionadded:: 1.11
+
+   Control wrapping of modules in executables.
+
+   Executables are made of compilation units whose names may collide with
+   libraries' compilation units. To avoid this possibility, Dune prefixes
+   these compilation unit names with ``Dune__exe__``. This is entirely
+   transparent to users except when such executables are debugged. In which
+   case, the mangled names will be visible in the debugger.
+
+   - with ``(wrapped_executables false)``, the original names are used.
+   - with ``(wrapped_executables true)``, the names are mangled.
+
+   Starting in language version 2.0, the default value is ``true``.

unikernel/duniverse/dune_/doc/reference/dune-workspace/config.rst

@@ -0,0 +1,6 @@
+``config`` stanzas
+------------------
+
+Starting in Dune 3.0, any of the stanzas from the :doc:`../config/index` file
+can be used in the ``dune-workspace`` file. In this case, the configuration
+stanza will only affect the current workspace.

unikernel/duniverse/dune_/doc/reference/dune-workspace/context.rst

@@ -0,0 +1,84 @@
+context
+-------
+
+The ``(context ...)`` stanza declares a build context. The argument can be
+either ``default`` or ``(default)`` for the default build context, or it can be
+the description of an opam switch, as follows:
+
+.. code:: dune
+
+    (context (opam (switch <opam-switch-name>)
+                   <optional-fields>))
+
+``<optional-fields>`` are:
+
+-  ``(name <name>)`` is the subdirectory's name for ``_build``, where this
+   build's context artifacts will be stored.
+
+-  ``(lock_dir <path>)`` specifies the lock directory that will be used for
+   building this context (if any). If no lock directory is specified
+   ``dune.lock`` will be used. See the
+   :doc:`/reference/dune-workspace/lock_dir` stanza for lock directory
+   configuration options.
+
+-  ``(root <opam-root>)`` is the opam root. By default, it will take the opam
+   root defined by the environment in which ``dune`` is run, which is usually
+   ``~/.opam``.
+
+- ``(merlin)`` instructs Dune to use this build context for Merlin.
+
+- ``(generate_merlin_rules)`` instructs Dune to generate Merlin rules for this
+  context, even if it is not the one selected via ``(merlin)``.
+
+- ``(profile <profile>)`` sets a different profile for a :term:`build context`. This has
+  precedence over the command-line option ``--profile``.
+
+- ``(env <env>)`` sets the environment for a particular context. This is of
+  higher precedence than the root ``env`` stanza in the workspace file. This
+  field has the same options as the :doc:`/reference/dune/env` stanza.
+
+- ``(toolchain <findlib_toolchain>)`` sets a ``findlib`` toolchain for the
+  context.
+
+- ``(host <host_context>)`` chooses a different context to build binaries that
+  are meant to be executed on the host machine, such as preprocessors.
+
+- ``(paths (<var1> <val1>) .. (<varN> <valN>))`` allows you to set the value of
+  any ``PATH``-like variables in this context. If ``PATH`` itself is modified in
+  this way, its value will be used to resolve workspace binaries, including
+  finding the compiler and related tools. These variables will also be passed as
+  part of the environment to any program launched by Dune. For each variable,
+  the value is specified using the :doc:`/reference/ordered-set-language`.
+  Relative paths are interpreted with respect to the workspace root. See
+  :ref:`finding-root`.
+
+- ``(fdo <target_exe>)`` builds this context with feedback-direct optimizations.
+  It requires `OCamlFDO <https://github.com/gretay-js/ocamlfdo>`__.
+  ``<target_exe>`` is a path-interpreted relative to the workspace root (see
+  :ref:`finding-root`). ``<target_exe>`` specifies which executable to optimize.
+  Users should define a different context for each target executable built with
+  FDO. The context name is derived automatically from the default name and
+  ``<target-exe>``, unless explicitly specified using the ``(name ...)`` field.
+  For example, if ``<target_exe>`` is *src/foo.exe* in a default context, then
+  the name of the context is *default-fdo-foo* and the filename that contains
+  execution counters is *src/fdo.exe.fdo-profile*.  This feature is
+  **experimental** and no backwards compatibility is implied.
+
+- By default, Dune builds and installs dynamically-linked foreign archives
+  (usually named ``dll*.so``). It's possible to disable this by setting by
+  including ``(disable_dynamically_linked_foreign_archives true)`` in the
+  workspace file, so bytecode executables will be built with all foreign
+  archives statically linked into the runtime system.
+
+
+Both ``(default ...)`` and ``(opam ...)`` accept a ``targets`` field in order to
+setup cross compilation. See :ref:`cross-compilation` for more information.
+
+Merlin reads compilation artifacts, and it can only read the compilation
+artifacts of a single context. Usually, you should use the artifacts from the
+``default`` context, and if you have the ``(context default)`` stanza in your
+``dune-workspace`` file, that is the one Dune will use.
+
+For rare cases where this is not what you want, you can force Dune to use a
+different build contexts for Merlin by adding the field ``(merlin)`` to this
+context.

unikernel/duniverse/dune_/doc/reference/dune-workspace/env.rst

@@ -0,0 +1,7 @@
+env
+---
+
+The ``env`` stanza can be used to set the base environment for all contexts in
+this workspace. This environment has the lowest precedence of all other ``env``
+stanzas. The syntax for this stanza is the same as Dune's
+:doc:`../dune/env` stanza.

unikernel/duniverse/dune_/doc/reference/dune-workspace/index.rst

@@ -0,0 +1,54 @@
+dune-workspace
+==============
+
+A ``dune-workspace`` file (if present) marks the root of the current Dune
+workspace (see :doc:`/explanation/scopes`). It can be used to define compilation contexts
+(see :doc:`/reference/dune-workspace/context`) and specify settings common to
+all Dune projects contained within the workspace.
+
+By default, a workspace has only one build context named ``default`` which
+corresponds to the environment in which ``dune`` is run. You can define more
+contexts by writing a ``dune-workspace`` file.
+
+You can point Dune to an explicit ``dune-workspace`` file with the
+``--workspace`` option. For instance, it's good practice to write a
+``dune-workspace.dev`` in your project with all the OCaml versions your projects
+support, so developers can test that the code builds with all OCaml versions by
+simply running:
+
+.. code:: console
+
+    $ dune build --workspace dune-workspace.dev @all @runtest
+
+The ``dune-workspace`` file uses the S-expression syntax. This is what a typical
+``dune-workspace`` file looks like:
+
+.. code:: dune
+
+    (lang dune 3.14)
+    (context (opam (switch 4.08.1)))
+    (context (opam (switch 4.11.1)))
+    (context (opam (switch 4.14.2)))
+
+The rest of this section describe the stanzas available.
+
+Note that an empty ``dune-workspace`` file is interpreted the same as one
+containing exactly:
+
+.. code:: dune
+
+    (lang dune 3.2)
+    (context default)
+
+This allows you to use an empty ``dune-workspace`` file to mark the root of your
+project.
+
+.. toctree::
+
+  config
+  context
+  env
+  lock_dir
+  pin
+  profile
+  repository

unikernel/duniverse/dune_/doc/reference/dune-workspace/lock_dir.rst

@@ -0,0 +1,80 @@
+lock_dir
+========
+
+.. warning::
+
+   :doc:`Dune Package Management </explanation/package-management>` is not
+   final yet and the configuration options are subject to change.
+
+This stanza configures the lock directory settings for the current workspace.
+For the default workflow no configuration is necessary, but the defaults can be
+changed if desired.
+
+.. describe:: (lock_dir ...)
+
+   .. versionadded:: 3.13
+
+   Configures a specific lock directory to be created or used.
+
+   .. describe:: (path <string>)
+
+      The location in the source tree where the lock directory will be
+      created or read from. If not specified defaults to ``dune.lock``.
+
+   .. describe:: (repositories <name list>)
+
+      The repositories to be used for finding a package solution, specified
+      in priority order. Supports ``:standard`` which contains ``upstream`` and
+      ``overlay``.
+
+      Additional repositories can be defined using the
+      :doc:`/reference/dune-workspace/repository` stanza.
+
+   .. describe:: (solver_env ...)
+
+      The environment that is injected into the solver when creating the lock
+      directory.
+
+      It consists of a sequence of ``(<name> <value>)`` pairs.
+
+   .. describe:: (unset_variables <name list>)
+
+      A list of variables that are used in solving that are deliberately unset
+      even if the solver could provide bindings for them.
+
+      The variables here cannot overlap with those defined in ``solver_env``.
+
+   .. describe:: (pins <name list>)
+
+      .. versionadded:: 3.15
+
+      Define which pins are enabled for this particular lock dir. See
+      :doc:`/reference/dune-workspace/pin` for details on how to define pins.
+
+   .. describe:: (version_preference <string>)
+
+      Can be one of:
+
+      - ``newest`` (default): The solver will pick the newest available
+         version of a package that satisfies the constraints.
+      - ``oldest``: The solver will pick the lowest version that will satisfy
+         the constraints
+
+   .. describe:: (constraints <dep-specification>)
+
+      Adds additional solver constraints that are passed to the solver. Follows
+      the :token:`~pkg-dep:dep_specification` format.
+
+      .. note::
+
+         Names introduced through ``constraints`` are not considered
+         dependencies and not added to the lockfile. They exist solely to add
+         additional constraints if the packages to which the constraint is
+         applied are selected and don't do anything otherwise.
+
+   .. describe:: (depopts <name list>)
+
+      .. versionadded:: 3.19
+
+      Defines which optional packages names (``depopts``) the solver should
+      include when attempting to find a solution for the project.

unikernel/duniverse/dune_/doc/reference/dune-workspace/pin.rst

@@ -0,0 +1,57 @@
+pin
+===
+
+.. warning::
+
+   :doc:`Dune Package Management </explanation/package-management>` is not
+   final yet and the configuration options are subject to change.
+
+This stanza is used to define additional package sources to use when locking a
+project and used for building dependencies.
+
+.. note::
+
+   Defining a pin does not enable it by default. It needs to be enabled in a
+   lock directory using the :doc:`/reference/dune-workspace/lock_dir` stanza.
+
+.. describe:: (pin ...)
+
+   .. versionadded:: 3.15
+
+   Defines a new package source.
+
+   .. describe:: (name <string>)
+
+      The name of the newly defined pin. This can be anything, it does not
+      have to match the package.
+
+      This must be specified.
+
+   .. describe:: (url <string>)
+
+      This can be a path to a directory on the local file system or remote Git
+      repository. Local paths can be absolute or relative, and may optionally
+      begin with ``file://`` though this is not necessary. Remote Git
+      repository URLs must begin with ``git+``, for example
+      ``git+https://github.com/user/repo`` or
+      ``git+git@github.com:user/repo.git``.
+
+      This must be specified.
+
+   .. describe:: (package ...)
+
+      Specifies the the packages to assign this pin to.
+
+      .. describe:: (name <string>)
+
+         The name of the package.
+
+         This must be specified.
+
+      .. describe:: (version <string>)
+
+         The version that the package should be assumed to be. Defaults to
+         ``dev`` if unspecified.
+
+.. seealso:: :doc:`pin stanza in dune-project </reference/dune-project/pin>` for
+   per-project pins.

unikernel/duniverse/dune_/doc/reference/dune-workspace/profile.rst

@@ -0,0 +1,11 @@
+profile
+-------
+
+The build profile can be selected in the ``dune-workspace`` file by write a
+``(profile ...)`` stanza. For instance:
+
+.. code:: dune
+
+    (profile release)
+
+Note that the command line option ``--profile`` has precedence over this stanza.

unikernel/duniverse/dune_/doc/reference/dune-workspace/repository.rst

@@ -0,0 +1,38 @@
+repository
+==========
+
+.. warning::
+
+   :doc:`Dune Package Management </explanation/package-management>` is not
+   final yet and the configuration options are subject to change.
+
+This stanza defines a new named package repository and attaches a source
+location to it.
+
+.. note::
+
+   Defining a repository does not enable it in project by default. It needs to be
+   enabled in a lock directory using the :doc:`/reference/dune-workspace/lock_dir`
+   stanza.
+
+.. describe:: (repository ...)
+
+   .. versionadded:: 3.12
+
+   Defines a named package repository.
+
+   .. describe:: (name <string>)
+
+      The name used to refer to the repository. Names have to be unique.
+
+      This must be specified.
+
+   .. describe:: (url <string>)
+
+      The location from which the repository will be loaded.
+
+      Both HTTP and Git locations can be specified, the latter allowing for
+      extensive control of the version by specifying an exact revision, tag or
+      branch.
+
+      This must be specified.

unikernel/duniverse/dune_/doc/reference/dune/alias.rst

@@ -0,0 +1,70 @@
+.. highlight:: dune
+
+alias
+-----
+
+.. describe:: (alias ...)
+
+   Add dependencies to an alias.
+
+   Aliases do not need to be explicitly created, adding to a new name will
+   "create" an alias.
+   An alias with name ``x`` can be built by running ``dune build @x``.
+   See :doc:`/reference/aliases`.
+
+   The common use of the ``alias`` stanza is make an alias depend on other ones::
+
+       (alias
+        (name runtest)
+        (deps
+         (alias test-unit)
+         (alias test-integration)))
+
+   .. warning::
+
+      In previous versions of the dune language, it was also possible to specify
+      an action to run to construct the alias. Please use a :doc:`rule` stanza
+      with the ``alias`` field instead.
+
+   This stanza supports the following fields:
+
+   .. describe:: (name <name>)
+
+      An alias name.
+
+      Attaching dependencies to ``(name x)`` will ensure they are built by
+      ``dune build @x``.
+
+      This field is required.
+
+   .. describe:: (deps <deps-conf list)
+
+      Specifies the dependencies of the alias.
+
+      See :doc:`/concepts/dependency-spec` for more details.
+
+      This field is required.
+
+   .. describe:: (enabled_if <blang expression>)
+
+      Specifies the Boolean condition that must be true for the tests to run.
+
+      The condition is specified using the :doc:`/reference/boolean-language`, and
+      the field allows for :doc:`/concepts/variables` to appear in the expressions.
+
+   .. describe:: (action <action>)
+
+      .. versionremoved :: 2.0 use :doc:`rule` with the ``alias`` field instead.
+
+      An :doc:`action </reference/actions/index>` for constructing the alias.
+
+   .. describe:: (package <name>)
+
+      Indicates that this alias stanza is part of package ``<name>`` and should be
+      filtered out if ``<name>`` is filtered out from the command line, either with
+      ``--only-packages <pkgs>`` or ``-p <pkgs>``.
+
+   .. describe:: (locks (<lock-names>))
+
+      Specifies that the action must be run while holding the following locks. See
+      :doc:`/concepts/locks` for more details.

unikernel/duniverse/dune_/doc/reference/dune/cinaps.rst

@@ -0,0 +1,5 @@
+cinaps
+------
+
+A ``cinaps`` stanza is available to support the ``cinaps`` tool.  See the
+`cinaps website <https://github.com/janestreet/cinaps>`_ for more details.

unikernel/duniverse/dune_/doc/reference/dune/copy_files.rst

@@ -0,0 +1,45 @@
+copy_files
+----------
+
+The ``copy_files`` and ``copy_files#`` stanzas specify that files from another
+directory could be copied to the current directory, if needed.
+
+The syntax is as follows:
+
+.. code:: dune
+
+    (copy_files
+     <optional-fields>
+     (files <glob>))
+
+``<glob>`` represents the set of files to copy. See the :ref:`glob <glob>` for
+details.
+
+``<optional-fields>`` are:
+
+- ``(alias <alias-name>)`` specifies an alias to which to attach the targets.
+
+- ``(mode <mode>)`` specifies how to handle the targets. See :ref:`modes` for
+  details.
+
+- ``(enabled_if <blang expression>)`` conditionally disables this stanza. The
+  condition is specified using the :doc:`/reference/boolean-language`.
+
+- ``(only_sources <blang expression>)`` specifies that the glob in ``files``
+  gets applied over the source tree, and not the build tree.
+
+The short form:
+
+.. code:: dune
+
+    (copy_files <glob>)
+
+is equivalent to:
+
+.. code:: dune
+
+    (copy_files (files <glob>))
+
+The difference between ``copy_files`` and ``copy_files#`` is the same as the
+difference between the ``copy`` and ``copy#`` actions. See
+:doc:`/reference/actions/index` section for more details.

unikernel/duniverse/dune_/doc/reference/dune/coq_theory.rst

@@ -0,0 +1,5 @@
+coq.theory
+----------
+
+See the documentation on the :ref:`coq-theory`, :ref:`coq-extraction`,
+:ref:`coq-pp`, and related stanzas.

unikernel/duniverse/dune_/doc/reference/dune/cram.rst

@@ -0,0 +1,112 @@
+Cram
+----
+
+.. describe:: (cram ...)
+
+   Configure Cram tests in the current directory (and subdirectories).
+
+   A single test may be configured by more than one ``cram`` stanza. In such
+   cases, the values from all applicable ``cram`` stanzas are merged together
+   to get the final values for all the fields.
+
+   .. seealso:: :doc:`/reference/cram`
+
+   .. describe:: (deps <dep-spec>)
+
+      Specify the dependencies of the test.
+
+      When testing binaries, it's important to to specify a dependency on the
+      binary for two reasons:
+
+      - Dune must know to re-run the test when a dependency changes
+      - The dependencies must be specified to guarantee that they're visible to
+        the test when running it.
+
+      The following introduces a dependency on ``foo.exe`` on all Cram tests in
+      this directory:
+
+      .. code:: dune
+
+         (cram
+          (deps ../foo.exe))
+
+      .. seealso:: :doc:`/concepts/dependency-spec`.
+
+   .. describe:: (applies_to <predicate-lang>)
+
+      Specify the scope of this ``cram`` stanza. By default it applies to all the
+      Cram tests in the current directory. The special ``:whole_subtree`` value
+      will apply the options to all tests in all subdirectories (recursively).
+      This is useful to apply common options to an entire test suite.
+
+      The following will apply the stanza to all tests in this directory,
+      except for ``foo.t`` and ``bar.t``:
+
+      .. code:: dune
+
+         (cram
+          (applies_to * \ foo bar)
+          (deps ../foo.exe))
+
+      .. seealso:: :doc:`/reference/predicate-language`
+
+   .. describe:: (enabled_if <blang>)
+
+      Control whether the tests are enabled.
+
+      .. seealso:: :doc:`/reference/boolean-language`, :doc:`/concepts/variables`
+
+   .. describe:: (alias <name>)
+
+      Alias that can be used to run the test. In addition to the user alias,
+      every test ``foo.t`` is attached to the :doc:`/reference/aliases/runtest`
+      alias and gets its own ``@foo`` alias to make it convenient to run
+      individually.
+
+   .. describe:: (locks <lock-names>)
+
+      Specify that the tests must be run while holding the following locks.
+
+      .. seealso:: :doc:`/concepts/locks`
+
+   .. describe:: (package <name>)
+
+      Attach the tests selected by this stanza to the specified package.
+
+   .. describe:: (runtest_alias <true|false>)
+
+      .. versionadded:: 3.12
+
+      When set to ``false``, do not add the tests to the ``runtest`` alias.
+      The default is to add every Cram test to ``runtest``, but this is not
+      always desired.
+
+   .. describe:: (timeout <float>)
+
+      .. versionadded:: 3.20
+
+      Specify a time limit (in seconds) for each individual Cram test.
+
+      If a test takes longer than the specified timeout, Dune will terminate it
+      and report a timeout error. This can be useful to catch tests that hang
+      or take unexpectedly long.
+
+      The timeout is a floating-point number (e.g., `1.5` for 1.5 seconds).
+      Zero or negative values cause immediate failure when running the cram
+      test.
+
+      If multiple ``cram`` stanzas apply to the same test, the **lowest** of
+      all specified timeouts is used.
+
+      This field is typically used to guard against unresponsive or
+      non-terminating test cases.
+
+      Example:
+
+      .. code:: dune
+
+         (cram
+          (timeout 2.5))
+
+      This limits each selected test to at most 2.5 seconds of execution time.
+

unikernel/duniverse/dune_/doc/reference/dune/data_only_dirs.rst

@@ -0,0 +1,18 @@
+data_only_dirs
+--------------
+
+.. versionadded:: 1.6
+
+Dune allows the user to treat directories as *data only*. ``dune`` files in
+these directories won't be evaluated for their rules, but the contents of these
+directories will still be usable as dependencies for other rules.
+
+The syntax is the same as for the ``dirs`` stanza except that ``:standard`` is
+empty by default.
+
+Example:
+
+.. code:: dune
+
+   ;; dune files in fixtures_* dirs are ignored
+   (data_only_dirs fixtures_*)

unikernel/duniverse/dune_/doc/reference/dune/deprecated_library_name.rst

@@ -0,0 +1,23 @@
+deprecated_library_name
+-----------------------
+
+The ``deprecated_library_name`` stanza enables redirecting an old deprecated
+name after a library has been renamed. It's syntax is as follows:
+
+.. code:: dune
+
+    (deprecated_library_name
+     (old_public_name <name>)
+     (new_public_name <name>))
+
+When a developer uses the old public name in a list of library dependencies, it
+will be transparently replaced by the new name. Note that it's not necessary for
+the new name to exist at definition time, as it is only resolved at the point
+where the old name is used.
+
+The ``old_public_name`` can also be one of the names declared in the
+``deprecated_package_names`` field of the package declaration in the
+``dune-project`` file. In this case, the "old" library is understood to be a
+library whose name is not prefixed by the package name. Such a library cannot be
+defined in Dune, but other build systems allow it. This feature is meant to help
+migration from those systems.

unikernel/duniverse/dune_/doc/reference/dune/dirs.rst

@@ -0,0 +1,40 @@
+dirs
+----
+
+.. versionadded:: 1.6
+
+The ``dirs`` stanza allows specifying the subdirectories Dune will include in a
+build. The syntax is based on Dune's :doc:`/reference/predicate-language` and
+allows the following operations:
+
+- The special value ``:standard`` which refers to the default set of used
+  directories. These are the directories that don't start with ``.`` or ``_``.
+
+- Set operations. Differences are expressed with backslash: ``* \ bar``; unions
+  are done by listing multiple items.
+
+- Sets can be defined using globs.
+
+Examples:
+
+.. code:: dune
+
+   (dirs *) ;; include all directories
+   (dirs :standard \ ocaml) ;; include all dirs except ocaml
+   (dirs :standard \ test* foo*) ;; exclude all dirs that start with test or foo
+
+Dune will not scan a directory that isn't included in this stanza. Any contained
+``dune`` (or other special) files won't be interpreted either and will be
+treated as raw data. It is however possible to depend on files inside ignored
+subdirectories.
+
+.. warning::
+
+  Directory names should not contain any trailing slashes.
+
+If you want to exclude a subdirectory, such as `foo/bar`, you need to use the
+:doc:`/reference/dune/subdir` stanza:
+
+.. code:: dune
+
+  (subdir foo (dirs :standard \ bar)) ;; exclude foo/bar

unikernel/duniverse/dune_/doc/reference/dune/documentation.rst

@@ -0,0 +1,30 @@
+documentation
+-------------
+
+Additional manual pages may be attached to packages using the ``documentation``
+stanza. These ``.mld`` files must contain text in the same syntax as OCamldoc
+comments.
+
+.. code-block:: dune
+
+  (documentation (<optional-fields>))
+
+Where ``<optional-fields>`` are:
+
+- ``(package <name>)`` defines the package this documentation should be attached
+  to. If this is absent, Dune will try to infer it based on the location of the
+  stanza.
+
+- ``(mld_files <arg>)``: the ``<arg>`` field follows the
+  :doc:`/reference/ordered-set-language`. This is a set of extensionless MLD file
+  basenames attached to the package, where ``:standard`` refers to all the
+  ``.mld`` files in the stanza's directory.
+
+- ``(files <arg>)``: the ``files`` field accepts the same arguments as the one
+  from the :ref:`install stanza <including-files-install-stanza>`. It allows to
+  install ``mld`` files as well as asset files, and specify where they are in the
+  hierarchy of documentation (with the ``as`` and ``with_prefix`` keyword). Note
+  that dune supports installing those files, but not yet building the
+  documentation with a non-flat hierarchy, or with non-mld files.
+
+For more information, see :ref:`documentation`.

unikernel/duniverse/dune_/doc/reference/dune/dynamic_include.rst

@@ -0,0 +1,31 @@
+.. _dynamic_include:
+
+dynamic_include
+---------------
+
+The ``dynamic_include`` stanza allows including the contents of another file in
+the current dune file like the ``include`` stanza.  However, the
+``dynamic_include`` stanza allows the included file to be the target of a rule
+and disallows generating some stanzas.
+
+For instance:
+
+.. code:: dune
+
+   (subdir b
+    (dynamic_include ../a/foo.inc))
+   (subdir a
+    (rule
+     (write-file
+      foo.inc
+      "(rule (write-file file bar))")))
+
+In the example above, the dynamic rule loading and generation are split into
+different directories to avoid rule loading cycles as rules are loaded per
+directory.
+
+The following stanzas cannot be dynamically generated:
+
+* Libraries, coq theories, library redirects
+* Public executables or install section with the ``bin`` section
+* Plugin stanzas

unikernel/duniverse/dune_/doc/reference/dune/env.rst

@@ -0,0 +1,97 @@
+env
+---
+
+The ``env`` stanza allows one to modify the environment. The syntax is as
+follows:
+
+.. code:: dune
+
+     (env
+      (<profile1> <settings1>)
+      (<profile2> <settings2>)
+      ...
+      (<profilen> <settingsn>))
+
+The first form ``(<profile> <settings>)`` that corresponds to the selected build
+profile will be used to modify the environment in this directory. You can use
+``_`` to match any build profile.
+
+Fields supported in ``<settings>`` are:
+
+- any OCaml flags field. See :doc:`/concepts/ocaml-flags` for more details.
+
+- ``(link_flags <flags>)`` specifies flags to OCaml when linking an executable.
+  See :ref:`executables stanza <shared-exe-fields>`.
+
+- ``(c_flags <flags>)`` and ``(cxx_flags <flags>)`` specify compilation flags
+  for C and C++ stubs, respectively. See :doc:`library` for more details.
+
+- ``(env-vars (<var1> <val1>) .. (<varN> <valN>))`` will add the corresponding
+  variables to the environment where the build commands are executed and are
+  used by ``dune exec``.
+
+- ``(menhir_flags <flags>))`` specifies flags for Menhir stanzas. This flag was
+  replaced by the ``(menhir)`` field (see below) starting in version 3.0 of the
+  Menhir extension.
+
+- ``(menhir (flags <flags>) (explain <blang expression>))`` specifies the Menhir
+  settings. See :doc:`menhir` for more details. This field was introduced in version
+  3.0 of the Menhir extension.
+
+- ``(js_of_ocaml (flags <flags>)(build_runtime <flags>)(link_flags <flags>))``
+  specifies ``js_of_ocaml`` flags. See :ref:`jsoo-field` for more details.
+
+- ``(js_of_ocaml (compilation_mode <mode>))`` controls whether to use separate
+  compilation or not where ``<mode>`` is either ``whole_program`` or
+  ``separate``.
+
+- ``(js_of_ocaml (sourcemap <mode>))`` controls whether to generate sourcemap
+  or not where ``<mode>`` is either ``no``, ``file`` (to generate sourcemap in a ``.map`` file next the the generated javascript file) or ``inline`` (to inline the sourcemap at the end of the generated JavaScript file).
+
+- ``(js_of_ocaml (runtest_alias <alias-name>))`` specifies the alias under which
+  :ref:`inline_tests` and tests (:ref:`tests-stanza`) run for the ``js`` mode.
+
+- ``(js_of_ocaml (enabled_if <blang expression>))`` specifies whether the ``js`` mode is enabled. It is enabled by default.
+
+- ``(wasm_of_ocaml (flags <flags>)(build_runtime <flags>)(link_flags <flags>))``
+  specifies ``wasm_of_ocaml`` flags. See :ref:`wasmoo-field` for more details.
+
+- ``(wasm_of_ocaml (compilation_mode <mode>))`` controls whether to use separate
+  compilation or not where ``<mode>`` is either ``whole_program`` or
+  ``separate``.
+
+- ``(wasm_of_ocaml (sourcemap <mode>))`` controls whether to generate sourcemap
+  or not where ``<mode>`` is either ``no``, ``file`` (to generate sourcemap in a ``.map`` file next the the generated javascript file) or ``inline`` (to inline the sourcemap at the end of the generated JavaScript file).
+
+- ``(wasm_of_ocaml (runtest_alias <alias-name>))`` specifies the alias under which
+  :ref:`inline_tests` and tests (:ref:`tests-stanza`) run for the ``wasm`` mode.
+
+- ``(wasm_of_ocaml (enabled_if <blang expression>))`` specifies whether the ``wasm`` mode is enabled. It is enabled by default.
+
+- ``(binaries <binaries>)``, where ``<binaries>`` is a list of entries of the
+  form ``(<filepath> as <name>)``. ``(<filepath> as <name>)`` makes the binary
+  ``<filepath>`` available in the command search as just ``<name>``. For
+  instance, in a ``(run <name> ...)`` action, ``<name>`` will resolve to this
+  file path. You can also write just the file path, in which case the name will
+  be inferred from the basename of ``<filepath>`` by dropping the ``.exe``
+  suffix, if it exists. For example, ``(binaries bin/foo.exe (bin/main.exe as
+  bar))`` would add the commands ``foo`` and ``bar`` to the search path.
+
+- ``(inline_tests <state>)``, where ``<state>`` is either ``enabled``,
+  ``disabled``, or ``ignored``. This field has been available since Dune 1.11.
+  It controls the variable's value ``%{inline_tests}``, which is read by the
+  inline test framework. The default value is ``disabled`` for the ``release``
+  profile and ``enabled`` otherwise.
+
+- ``(odoc <fields>)`` allows passing options to ``odoc``. See
+  :ref:`odoc-options` for more details.
+
+- ``(coq <coq_fields>)`` allow passing options to Coq. See :ref:`coq-env`
+  for more details.
+
+- ``(formatting <settings>)`` allows the user to set auto-formatting in the
+  current directory subtree (see
+  :doc:`/reference/dune-project/formatting`).
+
+- ``(bin_annot <bool>)`` allows the user to specify whether to generate `*.cmt`
+  and `*.cmti` in the current directory subtree.