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.

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

@@ -0,0 +1,357 @@
+executable
+----------
+
+The ``executable`` stanza must be used to describe an executable. The format of
+executable stanzas is as follows:
+
+.. code:: dune
+
+   (executable
+    (name <name>)
+    <optional-fields>)
+
+``<name>`` is a module name that contains the executable's main entry point.
+There can be additional modules in the current directory; you only need to
+specify the entry point. Given an ``executable`` stanza with ``(name <name>)``,
+Dune will know how to build ``<name>.exe``. If requested, it will also know how
+to build ``<name>.bc``, ``<name>.bc.js`` and ``<name>.bc.wasm.js`` (Dune 2.0
+and up also needs specific configuration (see the ``modes`` optional field
+below)).
+
+``<name>.exe`` is a native code executable, ``<name>.bc`` is a bytecode
+executable which requires ``ocamlrun`` to run, ``<name>.bc.js`` is a
+JavaScript generated using ``js_of_ocaml``, and ``<name>.bc.wasm.js`` is a
+Wasm loader script generated using ``wasm_of_ocaml`` (the Wasm modules are included in
+directory ``<name>.bc.wasm.assets``).
+
+Please note: in case native compilation is not available, ``<name>.exe`` will be
+a custom bytecode executable, in the sense of ``ocamlc -custom``. This means
+it's a native executable that embeds the ``ocamlrun`` virtual machine as well as
+the bytecode, so you can always rely on ``<name>.exe`` being available.
+Moreover, it is usually preferable to use ``<name>.exe`` in custom rules or when
+calling the executable by hand because running a bytecode executable often
+requires loading shared libraries that are locally built. This requires
+additional setup, such as setting specific environment variables, which Dune
+doesn't do at the moment.
+
+Native compilation isn't available when there is no ``ocamlopt`` binary at the
+same place as ``ocamlc`` was found.
+
+Executables can also be linked as object or shared object files. See `linking
+modes`_ for more information.
+
+Starting from Dune 3.0, it's possible to automatically generate empty interface
+files for executables. See
+:doc:`/reference/dune-project/executables_implicit_empty_intf`.
+
+``<optional-fields>`` are:
+
+- ``(public_name <public-name>)`` specifies that the executable should be
+  installed under this name. It's the same as adding the following stanza to
+  your ``dune`` file:
+
+   .. code:: dune
+
+      (install
+       (section bin)
+       (files (<name>.exe as <public-name>)))
+
+  As a special case, ``(public_name -)`` is the same as if the field was
+  absent.
+
+.. _shared-exe-fields:
+
+- ``(package <package>)`` if there is a ``(public_name ...)`` field, this
+  specifies the package the executables are part of it.
+
+- ``(libraries <library-dependencies>)`` specifies the library dependencies. See
+  :doc:`/reference/library-dependencies` for more details.
+
+- ``(link_flags <flags>)`` specifies additional flags to pass to the linker.
+  This field supports ``(:include ...)`` forms.
+
+- ``(link_deps (<deps-conf list>))`` specifies the dependencies used only by the
+  linker, i.e., when using a version script. See
+  :doc:`/concepts/dependency-spec` for more details.
+
+- ``(modules <modules>)`` specifies which modules in the current directory Dune
+  should consider when building this executable. Modules not listed here will be
+  ignored and cannot be used inside the executable described by the current
+  stanza. It is interpreted in the same way as the ``(modules ...)`` field of
+  :doc:`library`.
+
+- ``(root_module <module>)`` specifies a ``root_module`` that collects all
+  listed dependencies in ``libraries``. See the documentation for
+  ``root_module`` in the library stanza.
+
+- ``(modes (<modes>))`` sets the `linking modes`_. The default is ``(exe)``.
+  Before Dune 2.0, it formerly was ``(byte exe)``.
+
+- ``(preprocess <preprocess-spec>)`` is the same as the ``(preprocess ...)``
+  field of :doc:`library`.
+
+- ``(preprocessor_deps (<deps-conf list>))`` is the same as the ``(preprocessor_deps ...)`` field of :doc:`library`.
+
+- ``js_of_ocaml``: See the section about :ref:`jsoo-field`
+
+- ``wasm_of_ocaml``: See the section about :ref:`wasmoo-field`
+
+- ``flags``, ``ocamlc_flags``, and ``ocamlopt_flags``: See
+  :doc:`/concepts/ocaml-flags`.
+
+- ``(modules_without_implementation <modules>)`` is the same as the
+  corresponding field of :doc:`library`.
+
+- ``(allow_overlapping_dependencies)`` is the same as the corresponding field of
+  :doc:`library`.
+
+- ``(optional)`` is the same as the corresponding field of :doc:`library`.
+
+- ``(enabled_if <blang expression>)`` is the same as the corresponding field of
+  :doc:`library`.
+
+- ``(promote <options>)`` allows promoting the linked executables to the source
+  tree. The options are the same as for the :ref:`rule promote mode <promote>`.
+  Adding ``(promote (until-clean))`` to an ``executable`` stanza will cause Dune
+  to copy the ``.exe`` files to the source tree and use ``dune clean`` to delete
+  them.
+
+- ``(foreign_stubs <foreign-stubs-spec>)`` specifies foreign source files, e.g.,
+  C or C++ stubs, to be linked into the executable. See
+  :doc:`/reference/foreign-stubs` for more details.
+
+- ``(foreign_archives <foreign-archives-list>)`` specifies archives of foreign
+  object files to be linked into the executable. See the section
+  :doc:`/reference/foreign-archives` for more details.
+
+- ``(forbidden_libraries <libraries>)`` ensures that the given libraries are not
+  linked in the resulting executable. If they end up being pulled in, either
+  through a direct or transitive dependency, Dune fails with an error message
+  explaining how the library was pulled in. This field has been available since
+  Dune 2.0.
+
+- ``(embed_in_plugin_libraries <library-list>)`` specifies a list of libraries
+  to link statically when using the ``plugin`` linking mode. By default, no
+  libraries are linked in. Note that you may need to also use the ``-linkall``
+  flag if some of the libraries listed here are not referenced from any of the
+  plugin modules.
+
+- ``(ctypes <ctypes field>)`` instructs Dune to use ctypes stubgen to process
+  your type and function descriptions for binding system libraries, vendored
+  libraries, or other foreign code.  See :ref:`ctypes-stubgen` for a full
+  reference. This field is available since the 3.0 version of the Dune language.
+
+- ``(empty_module_interface_if_absent)`` causes the generation of empty
+  interfaces for every module that does not have an interface file already.
+  Useful when modules are used solely for their side-effects. This field is
+  available since the 3.0 version of the Dune language.
+
+Linking Modes
+~~~~~~~~~~~~~
+
+The ``modes`` field allows selecting which linking modes will be used to link
+executables. Each mode is a pair ``(<compilation-mode> <binary-kind>)``, where
+``<compilation-mode>`` describes whether the bytecode or native code backend of
+the OCaml compiler should be used and ``<binary-kind>`` describes what kind of
+file should be produced.
+
+``<compilation-mode>`` must be ``byte``, ``native``, or ``best``, where ``best``
+is ``native`` with a fallback to bytecode when native compilation isn't
+available.
+
+``<binary-kind>`` is one of:
+
+- ``c`` for producing OCaml bytecode embedded in a C file
+- ``exe`` for normal executables
+- ``object`` for producing static object files that can be manually linked into
+  C applications
+- ``shared_object`` for producing object files that can be dynamically loaded
+  into an application. This mode can be used to write a plugin in OCaml for a
+  non-OCaml application.
+- ``js`` for producing JavaScript from bytecode executables, see
+  :doc:`/reference/dune-project/explicit_js_mode`.
+- ``wasm`` for producing JavaScript from bytecode executables.
+- ``plugin`` for producing a plugin (``.cmxs`` if native or ``.cma`` if
+  bytecode).
+
+For instance the following ``executables`` stanza will produce bytecode
+executables and native shared objects:
+
+.. code:: dune
+
+   (executables
+     (names a b c)
+     (modes (byte exe) (native shared_object)))
+
+Additionally, you can use the following shorthands:
+
+- ``c`` for ``(byte c)``
+- ``exe`` for ``(best exe)``
+- ``object`` for ``(best object)``
+- ``shared_object`` for ``(best shared_object)``
+- ``byte`` for ``(byte exe)``
+- ``native`` for ``(native exe)``
+- ``js`` for ``(byte js)``
+- ``wasm`` for ``(byte wasm)``
+- ``plugin`` for ``(best plugin)``
+
+For instance, the following ``modes`` fields are all equivalent:
+
+.. code:: dune
+
+   (modes (exe object shared_object))
+   (modes ((best exe)
+           (best object)
+           (best shared_object)))
+
+Lastly, use the special mode ``byte_complete`` for building a bytecode
+executable as a native self-contained executable, i.e., an executable that
+doesn't require the ``ocamlrun`` program to run and doesn't require the C stubs
+to be installed as shared object files.
+
+The extensions for the various linking modes are chosen as follows:
+
+.. =========================== =================
+.. linking mode                extensions
+.. --------------------------- -----------------
+.. byte                        .bc
+.. native/best                 .exe
+.. byte_complete               .bc.exe
+.. (byte object)               .bc%{ext_obj}
+.. (native/best object)        .exe%{ext_obj}
+.. (byte shared_object)        .bc%{ext_dll}
+.. (native/best shared_object) %{ext_dll}
+.. c                           .bc.c
+.. js                          .bc.js
+.. wasm                        .bc.wasm.js
+.. (best plugin)               %{ext_plugin}
+.. (byte plugin)               .cma
+.. (native plugin)             .cmxs
+.. =========================== =================
+
+``%{ext_obj}`` and ``%{ext_dll}`` are the extensions for object and shared
+object files. Their value depends on the OS. For instance, on Unix
+``%{ext_obj}`` is usually ``.o`` and ``%{ext_dll}`` is usually ``.so``, while on
+Windows ``%{ext_obj}`` is ``.obj`` and ``%{ext_dll}`` is ``.dll``.
+
+Up to version 3.0 of the Dune language, when ``byte`` is specified but none of
+``native``, ``exe``, or ``byte_complete`` are specified, Dune implicitly adds a
+linking mode that's the same as ``byte_complete``, but it uses the extension
+``.exe``. ``.bc`` files require additional files at runtime that aren't
+currently tracked by Dune, so they don't run ``.bc`` files during the build. Run
+the ``.bc.exe`` or ``.exe`` ones instead, as these are self-contained.
+
+Lastly, note that ``.bc`` executables cannot contain C stubs. If your executable
+contains C stubs you may want to use ``(modes exe)``.
+
+.. _jsoo-field:
+
+js_of_ocaml
+~~~~~~~~~~~
+
+In ``library`` and ``executable`` stanzas, you can specify ``js_of_ocaml``
+options using ``(js_of_ocaml (<js_of_ocaml-options>))``.
+
+``<js_of_ocaml-options>`` are all optional:
+
+- ``(flags <flags>)`` to specify flags passed to ``js_of_ocaml compile``. This
+  field supports ``(:include ...)`` forms
+
+- ``(build_runtime_flags <flags>)`` to specify flags passed to ``js_of_ocaml
+  build-runtime``. This field supports ``(:include ...)`` forms
+
+- ``(link_flags <flags>)`` to specify flags passed to ``js_of_ocaml link``. This
+  field supports ``(:include ...)`` forms
+
+- ``(javascript_files (<files-list>))`` to specify ``js_of_ocaml`` JavaScript
+  runtime files.
+
+- ``(compilation_mode <mode>)`` where ``<mode>>`` is either ``whole_program`` or ``separate``.
+  This is only available inside ``executable`` stanzas.
+
+- ``(sourcemap <config>)`` where ``<config>>`` is one of ``no``, ``file`` or ``inline``.
+  This is only available inside ``executable`` stanzas.
+
+- ``(enabled_if <blang expression>)`` to specify whether the ``js`` mode is enabled. It is enabled by default.
+  This is only available inside ``executable`` stanzas.
+
+``<flags>`` is specified in the :doc:`/reference/ordered-set-language`.
+``<blang expression>`` is specified using the :doc:`/reference/boolean-language`,
+
+The default values for ``flags``, ``compilation_mode`` and ``sourcemap`` depend on the selected build profile. The
+build profile ``dev`` (the default) will enable inline sourcemap, separate compilation and pretty
+JavaScript output.
+
+See :ref:`jsoo` for more information.
+
+.. _wasmoo-field:
+
+wasm_of_ocaml
+~~~~~~~~~~~~~
+
+In ``library`` and ``executable`` stanzas, you can specify ``wasm_of_ocaml``
+options using ``(wasm_of_ocaml (<wasm_of_ocaml-options>))``.
+
+``<wasm_of_ocaml-options>`` are all optional. They are the same as the ``<js_of_ocaml-options>`` above plus:
+
+- ``(wasm_files (<files-list>))`` to specify ``wasm_of_ocaml``
+  Wasm runtime files.
+
+For the ``(sourcemap <config>)`` option, ``<config>`` must be one of ``no`` or ``inline``. Source maps are put within the ``.bc.wasm.assets``  directory.
+
+The default values for ``flags``, ``compilation_mode`` and ``sourcemap`` depend on the selected build profile. The
+build profile ``dev`` (the default) will enable sourcemaps, separate compilation and pretty Wasm output.
+
+See :ref:`wasmoo` for more information.
+
+executables
+-----------
+
+There is a very subtle difference in the naming of these stanzas. One is
+``executables``, plural, and the other is ``executable``, singular. The
+``executables`` stanza is very similar as the ``executable`` stanza but can be
+used to to describe several executables sharing the same configuration, so the
+plural ``executables`` stanza is used to describe more than one executable.
+
+
+It shares the same fields as the ``executable`` stanza, except that instead of
+``(name ...)`` and ``(public_name ...)`` you must use the plural versions as
+well:
+
+- ``(names <names>)`` where ``<names>`` is a list of entry point names. Compare
+  with ``executable``, where you only need to specify the modules containing the
+  entry point of each executable.
+
+- ``(public_names <names>)`` describes under what name to install each
+  executable. The list of names must be of the same length as the list in the
+  ``(names ...)`` field. Moreover, you can use ``-`` for executables that
+  shouldn't be installed.
+
+However, using ``executables`` the executables defined in the stanza are
+allowed to share modules.
+
+Given modules ``Foo``, ``Bar`` and ``Baz`` the usage of ``executables`` can
+simplify the code:
+
+.. code:: dune
+
+   (executables
+     (names foo bar))
+
+Instead of the more complex
+
+.. code:: dune
+
+   (library
+     (name baz)
+     (modules baz))
+   
+   (executable
+     (name foo)
+     (modules foo)
+     (libraries baz))
+   
+   (executable
+     (name bar)
+     (modules bar)
+     (libraries baz))

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

@@ -0,0 +1,7 @@
+foreign_library
+---------------
+
+The ``foreign_library`` stanza describes archives of separately compiled foreign
+object files that can be packaged with an OCaml library or linked into an OCaml
+executable. See :doc:`/reference/foreign-archives` for further details and
+examples.

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

@@ -0,0 +1,63 @@
+generate_sites_module
+---------------------
+
+.. versionadded:: 2.8
+
+Dune proposes some facilities for dealing with :ref:`sites<sites>` in a program.
+The ``generate_sites_module`` stanza will generate code for looking up the
+correct locations of the sites' directories and for loading plugins. It works
+after installation with or without the relocation mode, inside Dune rules, and
+when using Dune executables. For promotion, it works only if the generated
+modules are solely in the executable (or library statically linked) promoted;
+generated modules in plugins won't work.
+
+.. code:: dune
+
+   (generate_sites_module
+    (module <name>)
+    <facilities>)
+
+The module's code is generated in the directory with the given name. The code is
+populated according to the requested facilities.
+
+
+The available ``<facilities>`` are:
+
+- ``sourceroot`` adds a value ``val sourceroot: string option`` in the generated
+  module, which contains the value of ``%{workspace_root}``, if the code has
+  been built locally. It could be used to keep the tool's configuration file
+  locally when executed with ``dune exec`` or after promotion. The value is
+  ``None`` once it has been installed.
+
+- ``relocatable`` adds a value ``val relocatable: bool`` in the generated
+  module, which indicates if the binary has been installed in the relocatable
+  mode.
+
+- ``(sites <package>)`` adds a value ``val <site>: string list`` for each
+  ``<site>`` of ``<package>`` in the submodule `Sites` of the generated module.
+  The identifier <site> isn't capitalized.
+
+- ``(plugins (<package> <site>) ...)`` adds a submodule ``<site>`` with the
+  following signature ``S`` in the submodule ``Plugins`` of the generated module
+  . The identifier ``<site>`` is capitalized.
+
+.. code:: ocaml
+
+   module type S = sig
+     val paths: string list
+     (** return the locations of the directory containing the plugins *)
+
+     val list: unit -> string list
+     (** return the list of available plugins *)
+
+     val load_all: unit -> unit
+     (** load all the plugins and their dependencies *)
+
+     val load: string -> unit
+     (** load the specified plugin and its dependencies *)
+   end
+
+The generated module is a dependency on the library ``dune-site``, and if the
+facilities ``(plugins ...)`` are used, it is a dependency on the library
+``dune-site.plugins``. Those dependencies are not automatically added to the
+library or executable which use the module (cf. :ref:`plugins`).

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

@@ -0,0 +1,23 @@
+ignored_subdirs
+---------------
+
+.. deprecated:: 1.6
+
+One may also specify *data only* directories using the ``ignored_subdirs``
+stanza, meaning it's the same as ``data_only_dirs``, but the syntax isn't as
+flexible and only accepts a list of directory names. It's advised to switch to
+the new ``data_only_dirs`` stanza.
+
+Example:
+
+.. code:: dune
+
+     (ignored_subdirs (<sub-dir1> <sub-dir2> ...))
+
+All of the specified ``<sub-dirn>`` will be ignored by Dune. Note that users
+should rely on the ``dirs`` stanza along with the appropriate set operations
+instead of this stanza. For example:
+
+.. code:: dune
+
+  (dirs :standard \ <sub-dir1> <sub-dir2> ...)

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

@@ -0,0 +1,27 @@
+include
+-------
+
+The ``include`` stanza allows including the contents of another file in the
+current ``dune`` file. The included file cannot be generated and must
+be present in the source tree. To include generated files, 
+use the :ref:`dynamic_include` stanza instead. This feature is intended 
+for use in conjunction with promotion, when parts of a ``dune`` file are to be generated.
+
+For instance:
+
+.. code:: dune
+
+    (include dune.inc)
+
+    (rule (with-stdout-to dune.inc.gen (run ./gen-dune.exe)))
+
+    (rule
+     (alias  runtest)
+     (action (diff dune.inc dune.inc.gen)))
+
+With this ``dune`` file, running Dune as follows will replace the ``dune.inc``
+file in the source tree by the generated one:
+
+.. code:: console
+
+    $ dune build @runtest --auto-promote

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

@@ -0,0 +1,43 @@
+include_subdirs
+---------------
+
+The ``include_subdirs`` stanza is used to control how Dune considers
+subdirectories of the current directory. The syntax is as follows:
+
+.. code:: dune
+
+     (include_subdirs <mode>)
+
+Where ``<mode>`` maybe be one of:
+
+- ``no``, the default
+- ``unqualified``
+- ``qualified``
+
+When the ``include_subdirs`` stanza isn't present or ``<mode>`` is ``no``, Dune
+considers subdirectories independent. When ``<mode>`` is ``unqualified``, Dune
+will assume that the current directory's subdirectories are part of the same
+group of directories. In particular, Dune will simultaneously scan all these
+directories when looking for OCaml/Reason files. This allows you to split a
+library between several directories. ``unqualified`` means that modules in
+subdirectories are seen as if they were all in the same directory. In
+particular, you cannot have two modules with the same name in two different
+directories. When ``<mode>`` is ``qualified``, each subdirectory's files will
+be grouped into submodules of the library module, mirroring the directory
+structure.
+
+Note that subdirectories are included recursively; however, the recursion will
+stop when encountering a subdirectory that contains another ``include_subdirs``
+stanza. Additionally, it's not allowed for a subdirectory of a directory with
+``(include_subdirs <x>)`` where ``<x>`` is not ``no`` to contain one of the
+following stanzas:
+
+- ``library``
+- ``executable(s)``
+- ``test(s)``
+
+.. warning::
+
+   Currently the `(ocamllex)`, `(ocamlyacc)` and `(menhir)` stanzas do not work
+   well in combination with `(include_subdirs qualified)`. See `this issue
+   <https://github.com/ocaml/dune/issues/11119>`_ for more information.

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

@@ -0,0 +1,82 @@
+dune
+====
+
+``dune`` files are the main part of Dune. Each ``dune`` file belongs to a Dune
+project (see :doc:`/explanation/scopes`). They are used to describe libraries, executables,
+tests, and everything else Dune needs to know about.
+
+The syntax of ``dune`` files is described in
+:doc:`/reference/lexical-conventions`.
+
+``dune`` files are composed of stanzas, as shown below:
+
+.. code:: dune
+
+    (library
+     (name mylib)
+     (libraries base lwt))
+
+    (rule
+     (target foo.ml)
+     (deps   generator/gen.exe)
+     (action (run %{deps} -o %{target})))
+
+The following pages describe the available stanzas and their meanings.
+
+.. grid:: 1 2 1 3
+
+  .. grid-item::
+
+    .. toctree::
+      :caption: Components
+      :maxdepth: 1
+
+      executable
+      library
+      foreign_library
+      deprecated_library_name
+      generate_sites_module
+      test
+      cram
+      toplevel
+      documentation
+      install
+      plugin
+
+  .. grid-item::
+
+    .. toctree::
+      :caption: Project structure
+      :maxdepth: 1
+
+      rule
+      alias
+      copy_files
+      include
+      dynamic_include
+      env
+      dirs
+      data_only_dirs
+      ignored_subdirs
+      include_subdirs
+      vendored_dirs
+      subdir
+
+  .. grid-item::
+
+    .. toctree::
+      :caption: Integrations
+      :maxdepth: 1
+
+      cinaps
+      coq_theory
+      mdx
+      menhir
+      ocamllex
+      ocamlyacc
+
+    .. toctree::
+      :caption: Deprecated
+      :maxdepth: 1
+
+      jbuild_version

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

@@ -0,0 +1,286 @@
+install
+-------
+
+Dune supports installing packages on the system, i.e., copying freshly built
+artifacts from the workspace to the system. The ``install`` stanza takes three
+pieces of information:
+
+- The list of files or directories to install
+- The package to attach these files. This field is optional if your project
+  contains a single package.
+- The section in which the files will be installed
+
+For instance:
+
+.. code::
+
+   (install
+    (files hello.txt)
+    (section share)
+    (package mypackage))
+
+Indicate that the file ``hello.txt`` in the current directory is to be installed
+in ``<prefix>/share/mypackage``.
+
+The following sections are available:
+
+.. list-table::
+   :header-rows: 1
+
+   * - Section
+     - Target
+     - Remarks
+   * - ``lib``
+     - ``<prefix>/lib/<pkgname>/``
+     -
+   * - ``lib_root``
+     - ``<prefix>/lib/``
+     -
+   * - ``libexec``
+     - ``<prefix>/lib/<pkgname>/``
+     - executable bit is set
+   * - ``libexec_root``
+     - ``<prefix>/lib/``
+     - executable bit is set
+   * - ``bin``
+     - ``<prefix>/bin/``
+     - executable bit is set
+   * - ``sbin``
+     - ``<prefix>/sbin/``
+     - executable bit is set
+   * - ``toplevel``
+     - ``<prefix>/lib/toplevel/``
+     -
+   * - ``share``
+     - ``<prefix>/share/<pkgname>/``
+     -
+   * - ``share_root``
+     - ``<prefix>/share/``
+     -
+   * - ``etc``
+     - ``<prefix>/etc/<pkgname>/``
+     -
+   * - ``stublibs``
+     - ``<prefix>/lib/stublibs/``
+     - executable bit is set
+   * - ``doc``
+     - ``<prefix>/doc/<pkgname>/``
+     -
+   * - ``man``
+     - ``<prefix>/man/manX/``
+     - (see below)
+   * - ``misc``
+     - absolute destination
+     - (see below)
+   * - ``(site (<package> <site>))``
+     - ``<site>`` directory of ``<package>``
+     - (see below)
+
+Additional remarks:
+
+- For ``man``, the exact destination is inferred from the file extension. For
+  example, ``foo.1`` is installed as ``<prefix>/man/man1/foo.1``.
+- ``misc`` only works when using opam. In that case, the user will be prompted
+  before installation. This mechanism is deprecated.
+- In the case of ``(site)``, if the prefix isn't the same as the one used when installing ``<package>``, ``<package>`` won't find the files.
+
+Normally, Dune uses the file's basename to determine the file's name once
+installed; however, you can change that by using the form ``(<filename> as
+<destination>)`` in the ``files`` field. For instance, to install a file
+``mylib.el`` as ``<prefix>/emacs/site-lisp/mylib.el``, you must write the
+following:
+
+.. code:: dune
+
+    (install
+     (section share_root)
+     (files   (mylib.el as emacs/site-lisp/mylib.el)))
+
+The mode of installed files is fully determined by the section they are
+installed in. If the section above is documented as with the executable bit
+set, they are installed with mode ``0o755`` (``rwxr-xr-x``); otherwise they are
+installed with mode ``0o644`` (``rw-r--r--``).
+
+Note that all files in the install stanza must be specified by relative paths
+only. It is an error to specify files by absolute paths.
+
+Also note that as of dune-lang 3.11 (i.e., ``(lang dune 3.11)`` in
+``dune-project``) it is deprecated to use the ``as`` keyword to specify a
+destination beginning with ``..``. Dune intends for files associated with a
+package to only be installed under specific directories in the file system
+implied by the installation section (e.g., ``share``, ``bin``, ``doc``, etc.)
+and the package name. Starting destination paths with ``..`` allows packages to
+install files to arbitrary locations on the file system. In 3.11, this behaviour
+is still supported (as some projects may depend on it) but will generate a
+warning and will be removed in a future version of Dune.
+
+.. _including-files-install-stanza:
+
+Including Files in the Install Stanza
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can include external files from the ``files`` and ``dirs`` fields of the
+install stanza:
+
+.. code:: dune
+
+    (install
+     (files (include foo.sexp))
+     (section share))
+
+Here the file ``foo.sexp`` must contain a single S-expression list, whose
+elements will be included in the list of files or directories to install. That
+is, elements may be of the form:
+
+- ``<filename>``
+- ``(<filename> as <destination>)``
+- ``(include <filename>)``
+
+Included files may be generated by rules. Here is an example of a rule which
+generates a file by listing all the files in a subdirectory ``resources``:
+
+.. code:: dune
+
+    (rule
+     (deps (source_tree resources))
+     (action
+      (with-stdout-to foo.sexp
+      (system "echo '(' resources/* ')'"))))
+
+Globs in the Install Stanza
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can use globs to specify files to install by using the terms ``(glob_files
+<glob>)`` and ``(glob_files_rec <glob>)`` inside the ``files`` field of the
+install stanza (but not inside the ``dirs`` field). See the :ref:`glob <glob>`
+for details of the glob syntax. The ``(glob_files <glob>)`` term will expand its
+argument within a single directory, whereas the ``(glob_files_rec <glob>)`` term
+will recursively expand its argument within all subdirectories.
+
+For example:
+
+.. code:: dune
+
+    (install
+     (files
+      (glob_files style/*.css)
+      (glob_files_rec content/*.html))
+     (section share))
+
+This example will install:
+
+- All files matching ``*.css`` in the ``style`` directory.
+
+- All files matching ``*.html`` in the ``content`` directory, or any of its
+  descendant subdirectories.
+
+Note that the paths to files are preserved after installation. Suppose the
+source directory contained the files ``style/foo.css`` and
+``content/bar/baz.html``. The example above will place these files in
+``share/<package>/style/foo.css`` and ``share/<package>/content/bar/baz.html``
+respectively where ``<package>`` is the name of the package (ie.
+``dune-project`` would contain ``(package (name <package>))``).
+
+The ``with_prefix`` keyword can be used to change the destination path of files
+matched by a glob, similar to the ``as`` keyword in the ``(files ...)`` field.
+``with_prefix`` changes the prefix of a path before the component matched by the
+``*`` to some new value. For example:
+
+.. code:: dune
+
+    (install
+     (files
+      (glob_files (style/*.css with_prefix web/stylesheets))
+      (glob_files_rec (content/*.html with_prefix web/documents)))
+     (section share))
+
+Continuing the example above, this would result in the source file at
+``style/foo.css`` being installed to ``share/<package>/web/stylesheets/foo.css``
+and ``content/bar/baz.html`` being installed to
+``share/<package>/web/documents/bar/baz.html``. Note in the latter case
+``with_prefix`` only replaced the ``content`` component of the path and not the
+``bar`` component since it replaces the prefix of the glob - not the prefix
+of paths matching the glob.
+
+Installing Globs from Parent Directories
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The default treatment of paths in globs creates a complication where referring
+to globs in a parent directory such as ``(glob_files ../*.txt)`` would attempt
+to install the matched files outside the designated install directory. For
+example writing:
+
+.. code:: dune
+
+    (install
+     (files (glob_files ../*.txt))
+     (section share))
+
+...would cause Dune to attempt to install the matching files to
+``share/<package>/../``, ie. ``share`` where ``<package>`` is the name of the
+package (i.e., ``dune-project`` would contain ``(package (name <package>))``).
+This is probably not what the user intends, and installing files to relative
+paths beginning with ``..`` is deprecated from version 3.11 of Dune and will
+become an error in a future version.
+
+The solution is to use ``with_prefix`` to replace the ``..`` with some other
+path. For example:
+
+.. code:: dune
+
+    (install
+     (files (glob_files (../*.txt with_prefix .)))
+     (section share))
+
+...would install the matched files to ``share/<package>/`` instead.
+
+Handling of the .exe Extension on Windows
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Under Microsoft Windows, executables must be suffixed with ``.exe``. Dune tries
+to ensure that executables are always installed with this extension on Windows.
+
+More precisely, when installing a file via an ``(install ...)`` stanza, Dune
+implicitly adds the ``.exe`` extension to the destination, if the source file
+has extension ``.exe`` or ``.bc`` and if it's not already present
+
+Installing Source Directories
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To install entire source directories, the ``source_tree`` field can be used:
+
+.. code:: dune
+
+   (install
+    (section doc)
+    (source_trees manual))
+
+This example results in the contents of the ``manual`` directory being installed
+under ``<prefix>/doc/<package>/manual/``.
+
+As with ``(files ...)`` the destination can be changed with the ``as`` keyword.
+For example if you want to install all the files in the ``manual`` directory
+directly into ``<prefix>/doc/<package>/`` you can write:
+
+.. code:: dune
+
+   (install
+    (section doc)
+    (source_trees (manual as .)))
+
+It's also possible to specify multiple directories:
+
+.. code:: dune
+
+   (install
+    (section doc)
+    (source_trees manual examples))
+
+This would result in the local directories ``manual`` and ``examples`` being
+installed to ``<prefix>/doc/<package>/manual/`` and
+``<prefix>/doc/<package>/examples/`` respectively.
+
+Unlike with ``(files ...)`` it is an error to begin the destination (the
+right-hand side of ``as``) with ``..``. (This is because support for installing
+source directories was added to Dune after destinations beginning with ``..``
+were deprecated.)

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

@@ -0,0 +1,5 @@
+jbuild_version
+--------------
+
+Deprecated. This `jbuild_version` stanza is no longer used and will be removed
+in the future.

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

@@ -0,0 +1,335 @@
+library
+-------
+
+The ``library`` stanza must be used to describe OCaml libraries. The format of
+library stanzas is as follows:
+
+.. code:: dune
+
+    (library
+     (name <library-name>)
+     <optional-fields>)
+
+``<library-name>`` is the real name of the library. It determines the names of
+the archive files generated for the library as well as the module name under
+which the library will be available, unless ``(wrapped false)`` is used (see
+below). It must be a valid OCaml module name, but it doesn't need to start with
+an uppercase letter.
+
+For instance, the modules of a library named ``foo`` will be available as
+``Foo.XXX``, outside of ``foo`` itself; however, it is allowed to write an
+explicit ``Foo`` module, which will be the library interface. You are free to
+expose only the modules you want.
+
+Please note: by default, libraries and other things that consume OCaml/Reason
+modules only consume modules from the directory where the stanza appear. In
+order to declare a multi-directory library, you need to use the
+:doc:`include_subdirs` stanza.
+
+``<optional-fields>`` are:
+
+.. describe:: (public_name <name>)
+
+   The name under which the library can be referred as a dependency when it's
+   not part of the current workspace, i.e., when it's installed. Without a
+   ``(public_name ...)`` field, the library won't be installed by Dune. The
+   public name must start with the package name it's part of and optionally
+   followed by a dot, then anything else you want. The package name must also
+   be one of the packages that Dune knows about, as determined by the logic
+   described in :doc:`/reference/packages`.
+
+.. describe:: (package <package>)
+
+   Installs a private library under the specified package. Such a library is
+   now usable by public libraries defined in the same project. The Findlib name
+   for this library will be ``<package>.__private__.<name>``; however, the
+   library's interface will be hidden from consumers outside the project.
+
+.. describe:: (synopsis <string>)
+
+   A one-line description of the library. This is used by tools that list
+   installed libraries.
+
+.. describe:: (modules <modules>)
+
+   Specifies what modules are part of the library. By default, Dune will use
+   all the ``.ml/.re`` files in the same directory as the ``dune`` file. This
+   includes ones present in the file system as well as ones generated by user
+   rules. You can restrict this list by using a ``(modules <modules>)`` field.
+
+   ``<modules>`` uses the :doc:`/reference/ordered-set-language`, where
+   elements are module names and don't need to start with an uppercase letter.
+   For instance, to exclude module ``Foo``, use ``(modules (:standard \
+   foo))``.
+
+   Starting in Dune 3.13, one can also use special forms ``(:include <file>)``
+   and variables such as ``%{read-lines:<file>}`` in this field to customize
+   the list of modules using Dune rules. The dependencies introduced in this
+   way *must live in a different directory that the stanza making use of them*.
+
+.. describe:: (libraries <library-dependencies>)
+
+   Specifies the library's dependencies.
+
+   See :doc:`/reference/library-dependencies` for more details.
+
+.. describe:: (wrapped <boolean>)
+
+   Specifies whether the library modules should be available only through the
+   top-level library module, or if they should all be exposed at the top level.
+
+   The default is ``true``, and it's highly recommended to keep it this way.
+   Because OCaml top-level modules must all be unique when linking an
+   executables, polluting the top-level namespace will make your library
+   unusable with other libraries if there is a module name clash.
+
+   This option is only intended for libraries that manually prefix all their
+   modules by the library name and to ease porting of existing projects to
+   Dune.
+
+.. describe:: (wrapped (transition <message>))
+
+   This is the same as ``(wrapped true)``, except it will also generate
+   unwrapped (not prefixed by the library name) modules to preserve
+   compatibility.
+
+   This is useful for libraries that would like to transition from ``(wrapped
+   false)`` to ``(wrapped true)`` without breaking compatibility for users. The
+   deprecation notices for the unwrapped modules will include ``<message>``.
+
+.. describe:: (preprocess <preprocess-spec>)
+
+   Specifies how to preprocess files when needed.
+
+   The default is ``no_preprocessing``, and other options are described
+   in :doc:`/reference/preprocessing-spec`.
+
+.. describe:: (preprocessor_deps (<deps-conf list>))
+
+   Specifies extra preprocessor dependencies preprocessor, i.e., if the
+   preprocessor reads a generated file.
+
+   The specification of dependencies is described in
+   :doc:`/concepts/dependency-spec`.
+
+.. describe:: (optional)
+
+   If present, it indicates that the library should only be built and installed
+   if all the dependencies are available, either in the workspace or in the
+   installed world.
+
+   Use this to provide extra features without adding hard dependencies to your
+   project.
+
+.. describe:: (foreign_stubs <foreign-stubs-spec>)
+
+   Specifies foreign source files, e.g., C or C++ stubs, to be compiled and
+   packaged together with the library.
+
+   See the section :doc:`/reference/foreign-stubs` for more details.
+
+   This field replaces the now-deleted fields ``c_names``, ``c_flags``,
+   ``cxx_names``, and ``cxx_flags``.
+
+.. describe:: (foreign_archives <foreign-archives-list>)
+
+   Specifies archives of foreign object files to be packaged with the library.
+
+   See the section :doc:`/reference/foreign-archives` for more details. This
+   field replaces the now-deleted field ``self_build_stubs_archive``.
+
+.. describe:: (install_c_headers (<names>))
+
+   If your library has public C header files that must be installed, you must
+   list them in this field, without the ``.h`` extension.
+
+   You should favor the ``public_headers`` field starting from 3.8.
+
+.. describe:: (public_headers (<files>))
+
+   If your library has public C header files that must be installed, you must
+   list them in this field. This field accepts globs in the form of
+   ``(glob_files_rec <glob>)`` and ``(glob_files <glob>)`` fields to specify
+   multiple files.
+
+   The advantage of this field over ``install_c_headers`` is that it preserves
+   the directory structures of the headers relative to the library stanza.
+   Additionally, it allows to specify the extensions of the header files, which
+   allows alternative extensions such as ``.hh`` or ``.hpp``.
+
+.. describe:: (modes <modes>)
+
+   List modes which should be built by default.
+
+   The most common use for this feature is to disable native compilation when
+   writing libraries for the OCaml toplevel.
+
+   The following modes are available: ``byte``, ``native`` and ``best``.
+   ``best`` is ``native`` or ``byte`` when native compilation isn't available.
+
+.. describe:: (no_dynlink)
+
+   Disables (native) dynamic linking of the library. This means that the
+   ``.cmxs`` archive of the library will neither be built nor installed.
+
+   This is for advanced use only. By default, you shouldn't set this option.
+
+.. describe:: (kind <kind>)
+
+   Sets the type of library.
+
+   The default is ``normal``, but other available choices are ``ppx_rewriter``
+   and ``ppx_deriver``.
+
+   They must be set when the library is intended to be used as a PPX rewriter
+   or a ``[@@deriving ...]`` plugin. The reason ``ppx_rewriter`` and
+   ``ppx_deriver`` are split is historical, and hopefully we won't need two
+   options soon.
+
+   Both PPX kinds support an optional field: ``(cookies <cookies>)``, where
+   ``<cookies>`` is a list of pairs ``(<name> <value>)`` with ``<name>`` being
+   the cookie name and ``<value>`` a string that supports
+   :doc:`/concepts/variables` evaluated by each preprocessor invocation (note:
+   libraries that share cookies with the same name should agree on their
+   expanded value).
+
+.. describe:: (ppx_runtime_libraries (<library-names>))
+
+   This field is for when the library is a ``ppx rewriter`` or a ``[@@deriving
+   ...]`` plugin, and has runtime dependencies.
+
+   You need to specify these runtime dependencies here.
+
+.. describe:: (virtual_deps (<opam-packages>))
+
+   Sometimes opam packages enable a specific feature only if another package is
+   installed. For instance, the case of ``ctypes`` will only install
+   ``ctypes.foreign`` if the dummy ``ctypes-foreign`` package is installed.
+
+   You can specify such virtual dependencies here, but you don't need to do so
+   unless you use Dune to synthesize the ``depends`` and ``depopts`` sections
+   of your opam file.
+
+.. describe:: (js_of_ocaml ...)
+
+   Sets options for JavaScript compilation, see :ref:`jsoo-field`.
+
+.. describe:: (wasm_of_ocaml ...)
+
+   Sets options for JavaScript compilation, see :ref:`wasmoo-field`.
+
+.. describe:: (flags ...)
+
+   See :doc:`/concepts/ocaml-flags`.
+
+.. describe:: (ocamlc_flags ...)
+
+   See :doc:`/concepts/ocaml-flags`.
+
+.. describe:: (ocamlopt_flags ...)
+
+   See :doc:`/concepts/ocaml-flags`.
+
+.. describe:: (library_flags (<flags>))
+
+   A list of flags passed to ``ocamlc`` and ``ocamlopt`` when building the
+   library archive files.
+
+   You can use this to specify ``-linkall``, for instance.
+
+   ``<flags>`` is a list of strings supporting :doc:`/concepts/variables`.
+
+.. describe:: (c_library_flags <flags>)
+
+   Specifies the flags passed to the C compiler when constructing the library
+   archive file for the C stubs.
+
+   ``<flags>`` uses the :doc:`/reference/ordered-set-language` and supports
+   ``(:include ...)`` forms.
+
+   When you write bindings for a C library named ``bar``, you should typically
+   write ``-lbar`` here, or whatever flags are necessary to link against this
+   library.
+
+.. describe:: (modules_without_implementation <modules>)
+
+   Specifies a list of modules that have only a ``.mli`` or ``.rei`` but no ``.ml`` or ``.re`` file.
+
+   Such modules are usually referred as *mli only modules*. They are not
+   officially supported by the OCaml compiler; however, they are commonly used.
+   Such modules must only define types.
+
+   Since it isn't reasonably possible for Dune to check this is the case, Dune
+   requires the user to explicitly list such modules to avoid surprises.
+
+   Note that the ``modules_without_implementation`` field isn't merged in
+   ``modules``, which represents the total set of modules in a library. If a
+   directory has more than one stanza, and thus a ``modules`` field must be
+   specified, ``<modules>`` still needs to be added in ``modules``.
+
+.. describe:: (private_modules <modules>)
+
+   Specifies a list of modules that will be marked as private.
+
+   Private modules are inaccessible from outside the libraries they are defined
+   in.
+
+   Note that the ``private_modules`` field is not merged in ``modules``, which
+   represents the total set of modules in a library. If a directory has more
+   than one stanza and thus a ``modules`` field must be specified,
+   ``<modules>`` still need to be added in ``modules``.
+
+.. describe:: (allow_overlapping_dependencies)
+
+   Allows external dependencies to overlap with libraries that are present in
+   the workspace.
+
+.. describe:: (enabled_if <blang expression>)
+
+   Conditionally disables a library.
+
+   A disabled library cannot be built and will not be installed.
+
+   The condition is specified using the :doc:`/reference/boolean-language`, and
+   the field allows for the ``%{os_type}`` variable, which is expanded to the
+   type of OS being targeted by the current build. Its value is the same as the
+   value of the ``os_type`` parameter in the output of ``ocamlc -config``.
+
+.. describe:: (inline_tests)
+
+   Enables inline tests for this library.
+
+   They can be configured through options using ``(inline_tests <options>)``.
+
+   See :ref:`inline_tests` for a reference of corresponding options.
+
+.. describe:: (root_module <module>)
+
+   This field instructs Dune to generate a module that will contain module
+   aliases for every library specified in dependencies.
+
+   This is useful whenever a library is shadowed by a local module. The library
+   may then still be accessible via this root module.
+
+.. describe:: (ctypes <ctypes field>)
+
+   Instructs Dune to use ctypes stubgen to process your type and function
+   descriptions for binding system libraries, vendored libraries, or other
+   foreign code.
+
+   See :ref:`ctypes-stubgen` for a full reference.
+
+   This field is available since the 3.0 version of the Dune language.
+
+.. describe:: (empty_module_interface_if_absent)
+
+   Causes the generation of empty interfaces for every module that does not
+   have an interface file already.
+
+   Useful when modules are used solely for their side-effects. This field is
+   available since the 3.0 version of the Dune language.
+
+Note that when binding C libraries, Dune doesn't provide special support for
+tools such as ``pkg-config``; however, it integrates easily with
+:ref:`configurator` by using ``(c_flags (:include ...))`` and ``(c_library_flags
+(:include ...))``.

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

@@ -0,0 +1,75 @@
+mdx
+---
+
+.. versionadded:: 2.4
+
+MDX is a tool that helps you keep your markdown documentation up-to-date by
+checking that its code examples are correct. When setting an MDX stanza, the MDX
+checks are automatically attached to the ``runtest`` alias of the stanza's
+directory.
+
+See `MDX's repository <https://github.com/realworldocaml/mdx>`__ for more
+details.
+
+You can define an MDX stanza to specify which files you want checked.
+
+Note that this feature is still experimental and needs to be enabled in your
+``dune-project`` with the following ``using`` stanza:
+
+.. code:: dune
+
+  (using mdx 0.4)
+
+.. note:: Version ``0.2`` of the stanza requires mdx ``1.9.0``. Version ``0.4``
+   of the stanza requires mdx ``2.3.0``.
+
+
+The syntax is as follows:
+
+.. code:: dune
+
+  (mdx <optional-fields>)
+
+Where ``<optional-fields>`` are:
+
+- ``(files <globs>)`` are the files that you want MDX to check, described as a
+  list of globs (see the :ref:`Glob language specification <glob>` ). It
+  defaults to ``*.md *.mld`` as of version ``0.4`` of the stanza and ``*.md``
+  before.
+
+- ``(deps <deps-conf list>)`` to specify the dependencies of your documentation
+  code blocks. See :doc:`/concepts/dependency-spec` for more details.
+
+- ``(preludes <files>)`` are the prelude files you want to pass to MDX. See
+  `MDX's documentation <https://github.com/realworldocaml/mdx>`__ for more
+  details on preludes.
+
+- ``(libraries <libraries>)`` are libraries that should be statically linked in
+  the MDX test executable.
+
+- ``(enabled_if <blang expression>)``  is the same as the corresponding field of
+  :doc:`library`.
+
+- ``(package <package>)`` specifies which package to attach this stanza to
+  (similarly to when ``(package)`` is attached to a ``(rule)`` stanza). When
+  ``-p`` is passed, ``(mdx)`` stanzas with another package will be ignored. Note
+  that this feature is completely separate from ``(packages)``, which specifies
+  some dependencies.
+
+- ``(locks <lock-names>)`` specifies that the action of running the tests
+  holds the specified locks. See :doc:`/concepts/locks` for more details.
+
+Upgrading from Version 0.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- The 0.2 version of the stanza requires at least MDX 1.9.0. If you encounter an
+  error such as, ``ocaml-mdx: unknown command `dune-gen'``, then you should
+  upgrade MDX.
+
+- The field ``(packages <packages>)`` is deprecated in version 0.2. You can use
+  package items in the generic ``deps`` field instead: ``(deps (package
+  <package>) ... (package <package>))``
+
+- Use the new ``libraries`` field to directly link libraries in the test
+  executable and remove the need for ``#require`` directives in your
+  documentation code blocks.

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

@@ -0,0 +1,51 @@
+menhir
+------
+
+A ``menhir`` stanza is available to support the Menhir parser generator.
+
+To use Menhir in a Dune project, the language version should be selected in the
+``dune-project`` file. For example:
+
+.. code:: dune
+
+  (using menhir 3.0)
+
+This will enable support for Menhir stanzas in the current project. If the
+language version is absent, Dune will automatically add this line with the
+latest Menhir version once a Menhir stanza is used anywhere.
+
+The basic form for defining menhir_ parsers (analogous to :doc:`ocamlyacc`)
+is:
+
+.. code:: dune
+
+    (menhir
+     (modules <parser1> <parser2> ...)
+     <optional-fields>)
+
+``<optional-fields>`` are:
+
+- ``(merge_into <base_name>)`` is used to define modular parsers. This
+  correspond to the ``--base`` command line option of ``menhir``. With this
+  option, a single parser named ``base_name`` is generated.
+
+- ``(flags <option1> <option2> ...)`` is used to pass extra flags to Menhir.
+
+- ``(infer <bool>)`` is used to enable Menhir with type inference. This option
+  is enabled by default with Menhir language 2.0.
+
+Menhir supports writing the grammar and automation to the ``.cmly`` file.
+Therefore, if this is flag is passed to Menhir, Dune will know to introduce a
+``.cmly`` target for the module.
+
+- ``(explain <blang expression>)`` is used to control the generation of the
+  ``.conflicts`` file explaining conflicts found while generating the
+  parser. The condition is specified using the
+  :doc:`/reference/boolean-language`. This field was introduced in version 3.0
+  of the Menhir extension.
+
+Note that starting in version 3.0 of the Menhir extension, the ``.conflicts``
+file is generated by default. If this is not desired, it needs to be disabled
+explicitly by using the ``(explain)`` field.
+
+.. _menhir: https://gitlab.inria.fr/fpottier/menhir

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

@@ -0,0 +1,20 @@
+ocamllex
+--------
+
+``(ocamllex <names>)`` is essentially a shorthand for:
+
+.. code:: dune
+
+    (rule
+     (target <name>.ml)
+     (deps   <name>.mll)
+     (action (chdir %{workspace_root}
+              (run %{bin:ocamllex} -q -o %{target} %{deps}))))
+
+To use a different rule mode, use the long form:
+
+.. code:: dune
+
+    (ocamllex
+     (modules <names>)
+     (mode    <mode>))

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

@@ -0,0 +1,20 @@
+ocamlyacc
+---------
+
+``(ocamlyacc <names>)`` is essentially a shorthand for:
+
+.. code:: dune
+
+    (rule
+     (targets <name>.ml <name>.mli)
+     (deps    <name>.mly)
+     (action  (chdir %{workspace_root}
+               (run %{bin:ocamlyacc} %{deps}))))
+
+To use a different rule mode, use the long form:
+
+.. code:: dune
+
+    (ocamlyacc
+     (modules <names>)
+     (mode    <mode>))

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

@@ -0,0 +1,27 @@
+plugin
+------
+
+.. versionadded:: 2.8
+
+Plugins are a way to load OCaml libraries at runtime. The ``plugin`` stanza
+allows you to declare the plugin's name, which :ref:`sites<sites>` should be
+present and which libraries it will load.
+
+.. code:: dune
+
+   (plugin
+    (name <name>)
+    (libraries <libraries>)
+    (site (<package> <site name>))
+    (<optional-fields>))
+
+``<optional-fields>`` are:
+
+- ``(package <package>)`` if there is more than one package defined in the
+  current scope, this specifies which package the plugin will install. A plugin
+  can be installed by one package in the site of another package.
+
+- ``(optional)`` will not declare the plugin if the libraries are not available.
+
+The loading of the plugin is done using the facilities generated by
+:doc:`generate_sites_module`.

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

@@ -0,0 +1,148 @@
+rule
+----
+
+The ``rule`` stanza is used to create custom user rules. It tells Dune how to
+generate a specific set of files from a specific set of dependencies.
+
+The syntax is as follows:
+
+.. code:: dune
+
+    (rule
+     (action <action>)
+     <optional-fields>)
+
+``<action>`` is what you run to produce the targets from the dependencies. See
+:doc:`/reference/actions/index` for more details.
+
+``<optional-fields>`` are:
+
+- ``(target <filename>)`` or ``(targets <filenames>)`` is a list of filenames
+  (if defined with ``targets``) or exactly one filename (if defined with
+  ``target``). Dune needs to statically know targets of each rule.
+  ``(targets)`` can be omitted if it can be inferred from the action. See
+  `inferred rules`_.
+
+- ``(deps <deps-conf list>)`` specifies the dependencies of the rule. See
+  :doc:`/concepts/dependency-spec` for more details.
+
+- ``(mode <mode>)`` specifies how to handle the targets. See `modes`_ for
+  details.
+
+- ``(fallback)`` is deprecated and is the same as ``(mode fallback)``.
+
+- ``(locks (<lock-names>))`` specifies that the action must be run while holding
+  the following locks. See :doc:`/concepts/locks` for more details.
+
+- ``(alias <alias-name>)`` specifies this rule's alias. Building this alias
+  means building the targets of this rule.
+
+- ``(aliases <alias-name list>)`` specifies many aliases for this rule.
+
+- ``(package <package>)`` specifies this rule's package. This rule will be
+  unavailable when installing other packages in release mode.
+
+- ``(enabled_if <blang expression>)`` specifies the Boolean condition that must
+  be true for the rule to be considered. The condition is specified using the
+  :doc:`/reference/boolean-language`, and the field allows for
+  :doc:`/concepts/variables` to appear in the expressions.
+
+Please note: contrary to makefiles or other build systems, user rules currently
+don't support patterns, such as a rule to produce ``%.y`` from ``%.x`` for any
+given ``%``. This might be supported in the future.
+
+.. _modes:
+
+Modes
+~~~~~
+
+By default, a rule's target must not exist in the source tree because Dune will
+error out when this is the case; however, it's possible to change this behavior
+using the ``mode`` field. The following modes are available:
+
+- ``standard`` - the standard mode.
+
+- ``fallback`` - in this mode, when the targets are already present in the
+  source tree, Dune will ignore the rule. It's an error if only a subset of the
+  targets are present in the tree. Fallback rules are commonly used to generate
+  default configuration files that may be generated by a configure script.
+
+.. _promote:
+
+- ``promote`` or ``(promote <options>)`` - in this mode, the files in the source
+  tree will be ignored. Once the rule has been executed, the targets will be
+  copied back to the source tree. The following options are available:
+
+  - ``(until-clean)`` means that ``dune clean`` will remove the promoted files
+    from the source tree.
+  - ``(into <dir>)`` means that the files are promoted in ``<dir>`` instead of
+    the current directory. This feature has been available since Dune 1.8.
+  - ``(only <predicate>)`` means that only a subset of the targets should be
+    promoted. The argument is similar to the argument of :doc:`subdir`,
+    specified using the :doc:`/reference/predicate-language`.
+    This feature has been available since Dune 1.10.
+
+There are two use cases for ``promote`` rules. The first one is when the
+generated code is easier to review than the generator, so it's easier to commit
+the generated code and review it. The second is to cut down dependencies during
+releases. By passing ``--ignore-promoted-rules`` to Dune, rules with ``(mode
+promote)`` will be ignored, and the source files will be used instead. The
+``-p/--for-release-of-packages`` flag implies ``--ignore-promote-rules``.
+However, rules that promote only a subset of their targets via ``(only ...)``
+are never ignored.
+
+Inferred Rules
+~~~~~~~~~~~~~~
+
+When using the action DSL (see :doc:`/reference/actions/index`), the
+dependencies and targets are usually obvious.
+
+For instance:
+
+.. code:: dune
+
+    (rule
+     (target b)
+     (deps   a)
+     (action (copy %{deps} %{target})))
+
+In this example, the dependencies and targets are obvious by inspecting the
+action. When this is the case, you can use the following shorter syntax and have
+Dune infer dependencies and targets for you:
+
+.. code:: dune
+
+    (rule <action>)
+
+For instance:
+
+.. code:: dune
+
+    (rule (copy a b))
+
+Note that in Dune, targets must always be known statically. For instance, this
+``(rule ...)`` stanza is rejected by Dune:
+
+.. code:: dune
+
+    (rule (copy a b.%{read:file}))
+
+Directory targets
+~~~~~~~~~~~~~~~~~
+
+Note that at this time, Dune officially only supports user rules with targets in
+the current directory. However, starting from Dune 3.0, we provide an
+experimental support for *directory targets*, where an action can produce a
+whole tree of build artifacts. To specify a directory target, you can use the
+``(dir <dirname>)`` syntax. For example, the following stanza describes a rule
+with a file target ``foo`` and a directory target ``bar``.
+
+.. code:: dune
+
+    (rule
+     (targets foo (dir bar))
+     (action  <action>))
+
+To enable this experimental feature, add ``(using directory-targets 0.1)`` to
+your ``dune-project`` file. However note that currently rules with a directory
+target are always rebuilt. We are working on fixing this performance bug.

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

@@ -0,0 +1,14 @@
+subdir
+------
+
+The ``subdir`` stanza can be used to evaluate stanzas in subdirectories. This is
+useful for generated files or to override stanzas in vendored directories
+without editing vendored ``dune`` files.
+
+In this example, a ``bar`` target is created in the ``foo`` directory, and a bar
+target will be created in ``a/b/bar``:
+
+.. code:: dune
+
+   (subdir foo (rule (with-stdout-to bar (echo baz))))
+   (subdir a/b (rule (with-stdout-to bar (echo baz))))

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

@@ -0,0 +1,60 @@
+test
+----
+
+The ``test`` stanza is the singular form of ``tests``. The only difference is
+that it's of the form:
+
+.. code:: dune
+
+   (test
+    (name foo)
+    <optional fields>)
+
+The ``name`` field is singular, and the same optional fields are supported.
+
+.. _tests-stanza:
+
+tests
+-----
+
+The ``tests`` stanza allows one to easily define multiple tests. For example, we
+can define two tests at once with:
+
+.. code:: dune
+
+   (tests
+    (names mytest expect_test)
+    <optional fields>)
+
+This defines an executable named ``mytest.exe``. These tests can be run by
+building the aliases ``runtest-mytest`` and ``runtest-expect_test``
+respectively. They will also be added to the ``runtest`` alias.
+
+If the directory also contains an ``expect_test.expected`` file, then
+``expect_test`` will be used to define an expect test. That is, the test will be
+executed and its output will be compared to ``expect_test.expected``.
+
+The optional fields supported are a subset of the alias and executables fields.
+In particular, all fields except for ``public_names`` are supported from the
+:ref:`executables stanza <shared-exe-fields>`. Alias fields apart from ``name``
+are allowed.
+
+The ``(enabled_if)`` field has special semantics: when present, it only applies
+to running the tests. The test executable is always built by default.
+If you need to restrict building the test executable, use ``(build_if)`` instead.
+
+By default, the test binaries are run without options.  The ``action`` field can
+override the test binary invocation, i.e., if you're using Alcotest and wish to
+see all the test failures on the standard output. When running Dune ``runtest``
+you can use the following stanza:
+
+.. code:: dune
+
+   (tests
+    (names mytest)
+    (libraries alcotest mylib)
+    (action (run %{test} -e)))
+
+Starting from Dune 2.9, it's possible to automatically generate empty interface
+files for test executables. See
+:doc:`/reference/dune-project/executables_implicit_empty_intf`.

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

@@ -0,0 +1,23 @@
+toplevel
+--------
+
+The ``toplevel`` stanza allows one to define custom toplevels. Custom toplevels
+automatically load a set of specified libraries and are runnable like normal
+executables. Example:
+
+.. code:: dune
+
+   (toplevel
+    (name tt)
+    (libraries str))
+
+This will create a toplevel with the ``str`` library loaded. We may build and
+run this toplevel with:
+
+.. code:: console
+
+   $ dune exec ./tt.exe
+
+``(preprocess (pps ...))`` is the same as the ``(preprocess (pps ...))`` field
+of :doc:`library`. Currently, ``action`` and ``future_syntax`` are not
+supported in the toplevel.

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

@@ -0,0 +1,22 @@
+vendored_dirs
+-------------
+
+.. versionadded:: 1.11
+
+Dune supports vendoring other Dune-based projects natively, since simply copying
+a project into a subdirectory of your own project will work. Simply doing that
+has a few limitations though. You can workaround those by explicitly marking
+such directories as containing vendored code.
+
+Example:
+
+.. code:: dune
+
+   (vendored_dirs vendor)
+
+
+Dune will not resolve aliases in vendored directories. By default, it won't
+build all installable targets, run the tests, format, or lint the code located
+in such a directory while still building your project's dependencies. Libraries
+and executables in vendored directories will also be built with a ``-w -a`` flag
+to suppress all warnings and prevent pollution of your build output.