matthieu
/
dune
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix links in rst docs 

Were not converted correctly by pandoc so they must be fixed manually
This commit is contained in:
Rudi Grinberg 2017-05-18 16:15:49 -04:00 committed by Jérémie Dimino
parent c0e0dfc107
commit 1309a92ec5
5 changed files with 135 additions and 130 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/advanced-topics.rst
View File

@ -37,6 +37,8 @@ just write or generate a ``META.<package>.template`` file containing a
line of the form ``# JBUILDER_GEN``. Jbuilder will automatically insert line of the form ``# JBUILDER_GEN``. Jbuilder will automatically insert
its generated ``META`` contents in place of this line. its generated ``META`` contents in place of this line.
.. _custom-driver:
Using a custom ppx driver Using a custom ppx driver
========================= =========================

233
doc/jbuild.rst
View File

@ -64,7 +64,7 @@ modules you want.
will not be installed by Jbuilder. The public name must start by the package will not be installed by Jbuilder. The public name must start by the package
name it is part of and optionally followed by a dot and anything else you name it is part of and optionally followed by a dot and anything else you
want. The package name must be one of the packages that Jbuilder knows about, want. The package name must be one of the packages that Jbuilder knows about,
as determined by the *<package>.opam files* as determined by the :ref:`opam-files`
- ``(synopsis <string>)`` should give a one-line description of the library. - ``(synopsis <string>)`` should give a one-line description of the library.
This is used by tools that list installed libraries This is used by tools that list installed libraries
@ -73,13 +73,14 @@ modules you want.
default Jbuilder will use all the .ml/.re files in the same directory as the default Jbuilder will use all the .ml/.re files in the same directory as the
``jbuild`` file. This include ones that are present in the file system as ``jbuild`` file. This include ones that are present in the file system as
well as ones generated by user rules. You can restrict this list by using a well as ones generated by user rules. You can restrict this list by using a
``(modules <modules>)`` field. ``<modules>`` uses the *ordered set language* ``(modules <modules>)`` field. ``<modules>`` uses the `Ordered set language`_
where elements are module names and don't need to start with a uppercase where elements are module names and don't need to start with a uppercase
letter. For instance to exclude module ``Foo``: ``(modules (:standard \ letter. For instance to exclude module ``Foo``: ``(modules (:standard \
foo))`` foo))``
- ``(libraries (<library-dependencies>))`` is used to specify the dependencies - ``(libraries (<library-dependencies>))`` is used to specify the dependencies
of the library. See the *section about library dependencies* for more details of the library. See the section about `Library dependencies`_ for more
details
- ``(wrapped <boolean>)`` specifies whether the modules of the library should be - ``(wrapped <boolean>)`` specifies whether the modules of the library should be
available only through the top-level library module, or should all be exposed available only through the top-level library module, or should all be exposed
@ -92,12 +93,12 @@ modules you want.
- ``(preprocess <preprocess-spec>)`` specifies how to preprocess files if - ``(preprocess <preprocess-spec>)`` specifies how to preprocess files if
needed. The default is ``no_processing``. Other options are described in the needed. The default is ``no_processing``. Other options are described in the
*preprocessing specification section* `Preprocessing specification`_ section
- ``(preprocessor_deps (<deps-conf list>))`` specifies extra dependencies of the - ``(preprocessor_deps (<deps-conf list>))`` specifies extra dependencies of the
preprocessor, for instance if the preprocessor reads a generated file. The preprocessor, for instance if the preprocessor reads a generated file. The
specification of dependencies is described in the *dependency specification specification of dependencies is described in the `Dependency specification`_
section* section
- ``(optional)``, if present it indicates that the library should only be built - ``(optional)``, if present it indicates that the library should only be built
and installed if all the dependencies are available, either in the workspace and installed if all the dependencies are available, either in the workspace
@ -136,18 +137,18 @@ modules you want.
dependencies here. You don't need to do so unless you use Jbuilder to dependencies here. You don't need to do so unless you use Jbuilder to
synthesize the ``depends`` and ``depopts`` sections of your opam file synthesize the ``depends`` and ``depopts`` sections of your opam file
- ``js_of_ocaml``. See the *section about js_of_ocaml* - ``js_of_ocaml``. See the section about :ref:`jbuild-jsoo`
- ``flags``, ``ocamlc_flags`` and ``ocamlopt_flags``. See the - ``flags``, ``ocamlc_flags`` and ``ocamlopt_flags``. See the section about
*section about specifying OCaml flags* `OCaml flags`_
- ``(library_flags (<flags>))`` is a list of flags that are passed as it to - ``(library_flags (<flags>))`` is a list of flags that are passed as it to
``ocamlc`` and ``ocamlopt`` when building the library archive files. You can ``ocamlc`` and ``ocamlopt`` when building the library archive files. You can
use this to specify ``-linkall`` for instance. ``<flags>`` is a list of use this to specify ``-linkall`` for instance. ``<flags>`` is a list of
strings supporting *variables expansion* strings supporting `Variables expansion`_
- ``(c_flags <flags>)`` specifies the compilation flags for C stubs, - ``(c_flags <flags>)`` specifies the compilation flags for C stubs,
using the *ordered set language*. This field supports using the `Ordered set language`_. This field supports
``(:include ...)`` forms ``(:include ...)`` forms
- ``(cxx_flags <flags>)`` is the same as ``c_flags`` but for C++ - ``(cxx_flags <flags>)`` is the same as ``c_flags`` but for C++
@ -155,7 +156,7 @@ modules you want.
- ``(c_library_flags <flags>)`` specifies the flags to pass to the C compiler - ``(c_library_flags <flags>)`` specifies the flags to pass to the C compiler
when constructing the library archive file for the C stubs. ``<flags>`` uses when constructing the library archive file for the C stubs. ``<flags>`` uses
the *ordered set language* and supports ``(:include ...)`` forms. When you the `Ordered set language`_ and supports ``(:include ...)`` forms. When you
are writing bindings for a C library named ``bar``, you should typically are writing bindings for a C library named ``bar``, you should typically
write ``-lbar`` here, or whatever flags are necessary to to link against this write ``-lbar`` here, or whatever flags are necessary to to link against this
library library
@ -215,26 +216,25 @@ such you can always rely on ``<name>.exe`` being available.
- ``(package <package>)`` if there is a ``(public_name ...)`` field, - ``(package <package>)`` if there is a ``(public_name ...)`` field,
this specifies the package the executables are part of this specifies the package the executables are part of
- ``(libraries (<library-dependencies>))`` specifies the library - ``(libraries (<library-dependencies>))`` specifies the library dependencies.
dependencies. See the *section about library dependencies* for See the section about `Library dependencies`_ for more details
more details
- ``(modules <modules>)`` specifies which modules in the current - ``(modules <modules>)`` specifies which modules in the current directory
directory Jbuilder should consider when building this executable. Jbuilder should consider when building this executable. Modules not listed
Modules not listed here will be ignored and cannot be used inside here will be ignored and cannot be used inside the executable described by
the executable described by the current stanza. It is interpreted the current stanza. It is interpreted in the same way as the ``(modules
in the same way as the ``(modules ...)`` field of *libraries* ...)`` field of `library`_
- ``(preprocess <preprocess-spec>)`` is the same as the - ``(preprocess <preprocess-spec>)`` is the same as the ``(preprocess ...)``
``(preprocess ...)`` field of *libraries* field of `library`_
- ``(preprocessor_deps (<deps-conf list>))`` is the same as the - ``(preprocessor_deps (<deps-conf list>))`` is the same as the
``(preprocessor_deps ...)`` field of *libraries* ``(preprocessor_deps ...)`` field of `library`_
- ``js_of_ocaml``. See the *section about js_of_ocaml* - ``js_of_ocaml``. See the section about `js_of_ocaml`_
- ``flags``, ``ocamlc_flags`` and ``ocamlopt_flags``. See the - ``flags``, ``ocamlc_flags`` and ``ocamlopt_flags``. See the section about
*section about specifying OCaml flags* specifying `OCaml flags`_
executables executables
----------- -----------
@ -274,11 +274,11 @@ The syntax is as follows:
``<filenames>`` is a list of file names. Note that currently Jbuilder ``<filenames>`` is a list of file names. Note that currently Jbuilder
only support user rules with targets in the current directory. only support user rules with targets in the current directory.
``<deps-conf list>`` specifies the dependencies of the rule. See the ``<deps-conf list>`` specifies the dependencies of the rule. See the `Dependency
*dependency specification section* for more details. specification`_ section for more details.
``<action>`` is the action to run to produce the targets from the ``<action>`` is the action to run to produce the targets from the dependencies.
dependencies. See the *actions section* for more details. See the `User actions`_ section for more details.
Note that contrary to makefiles or other build systems, user rules Note that contrary to makefiles or other build systems, user rules
currently don't support patterns, such as a rule to produce ``%.y`` currently don't support patterns, such as a rule to produce ``%.y``
@ -356,12 +356,12 @@ The syntax is as follows:
``<name>`` is an alias name such as ``runtest``. ``<name>`` is an alias name such as ``runtest``.
``<deps-conf list>`` specifies the dependencies of the alias. See the ``<deps-conf list>`` specifies the dependencies of the alias. See the
*dependency specification section* for more details. `Dependency specification`_ section for more details.
``<optional-fields>`` are: ``<optional-fields>`` are:
- ``<action>``, an action to run when constructing the alias. See - ``<action>``, an action to run when constructing the alias. See
the *actions section* for more details. the `User actions`_ section for more details.
- ``(package <name>)`` indicates that this alias stanza is part of - ``(package <name>)`` indicates that this alias stanza is part of
package ``<name>`` and should be filtered out if ``<name>`` is package ``<name>`` and should be filtered out if ``<name>`` is
@ -376,7 +376,7 @@ The typical use of the ``alias`` stanza is to define tests:
((name runtest) ((name runtest)
(action (run ${exe:my-test-program.exe} blah)))) (action (run ${exe:my-test-program.exe} blah))))
See the *section about running tests* for details. See the section about :ref:`running-tests` for details.
Note that if your project contains several packages and you run test the tests Note that if your project contains several packages and you run test the tests
from the opam file using a ``build-test`` field, then all your ``runtest`` alias from the opam file using a ``build-test`` field, then all your ``runtest`` alias
@ -451,7 +451,7 @@ syntax ``(:include <filename>)``. This is useful for instance when you need to
run a script to figure out some compilation flags. ``<filename>`` is expected to run a script to figure out some compilation flags. ``<filename>`` is expected to
contain a single S-expression and cannot contain ``(:include ...)`` forms. contain a single S-expression and cannot contain ``(:include ...)`` forms.
Most fields using the ordered set language also support *variables expansion*. Most fields using the ordered set language also support `Variables expansion`_.
Variables are expanded after the set language is interpreted. Variables are expanded after the set language is interpreted.
Variables expansion Variables expansion
@ -480,31 +480,27 @@ Jbuilder supports the following variables:
In addition, ``(action ...)`` fields support the following special variables: In addition, ``(action ...)`` fields support the following special variables:
- ``@`` expands to the list of target, separated by spaces - ``@`` expands to the list of target, separated by spaces
- ``<`` expands to the first dependency, or the empty string if - ``<`` expands to the first dependency, or the empty string if there are no
there are no dependencies dependencies
- ``^`` expands to the list of dependencies, separated by spaces - ``^`` expands to the list of dependencies, separated by spaces
- ``path:<path>`` expands to ``<path>`` - ``path:<path>`` expands to ``<path>``
- ``exe:<path>`` is the same as ``<path>``, except when - ``exe:<path>`` is the same as ``<path>``, except when cross-compiling, in
cross-compiling, in which case it will expand to ``<path>`` which case it will expand to ``<path>`` from the host build context
from the host build context - ``bin:<program>`` expands to a path to ``program``. If ``program`` is
- ``bin:<program>`` expands to a path to ``program``. If installed by a package in the workspace (see `install`_ stanzas), the locally
``program`` is installed by a package in the workspace (see built binary will be used, otherwise it will be searched in the ``PATH`` of
*install stanzas*), the locally built binary will be used, the current build context
otherwise it will be searched in the ``PATH`` of the current - ``lib:<public-library-name>:<file>`` expands to a path to file ``<file>`` of
build context library ``<public-library-name>``. If ``<public-library-name>`` is available
- ``lib:<public-library-name>:<file>`` expands to a path to file in the current workspace, the local file will be used, otherwise the one from
``<file>`` of library ``<public-library-name>``. If
``<public-library-name>`` is available in the current
workspace, the local file will be used, otherwise the one from
the installed world will be used the installed world will be used
- ``libexec:<public-library-name>:<file>`` is the same as - ``libexec:<public-library-name>:<file>`` is the same as ``lib:...`` except
``lib:...`` except when cross-compiling, in which case it will when cross-compiling, in which case it will expand to the file from the host
expand to the file from the host build context build context
- ``lib-available:<library-name>`` expands to ``true`` or - ``lib-available:<library-name>`` expands to ``true`` or ``false`` depending on
``false`` depending on wether the library is available or not. wether the library is available or not. A library is available iff at least
A library is available iff at least one of the following one of the following condition holds:
condition holds:
- it is part the installed worlds - it is part the installed worlds
- it is available locally and is not optional - it is available locally and is not optional
@ -521,51 +517,48 @@ transparently whether things are installed or not.
Library dependencies Library dependencies
-------------------- --------------------
Dependencies on libraries are specified using ``(libraries ...)`` Dependencies on libraries are specified using ``(libraries ...)`` fields in
fields in ``library`` and ``executables`` stanzas. ``library`` and ``executables`` stanzas.
For libraries that are present in the workspace, you can use For libraries that are present in the workspace, you can use either the real
either the real name (with some restrictions, see below) or the name (with some restrictions, see below) or the public name. For libraries that
public name. For libraries that are part of the installed world, are part of the installed world, you need to use the public name. For instance:
you need to use the public name. For instance:
``(libraries (base re))``. ``(libraries (base re))``.
When resolving libraries, libraries that are part of the workspace When resolving libraries, libraries that are part of the workspace are always
are always prefered to ones that are part of the installed world. prefered to ones that are part of the installed world.
#. Scope of internal library names #. Scope of internal library names
The scope of internal library names is not the whole workspace. The scope of internal library names is not the whole workspace. It is
It is restricted to the subtree starting from the closest restricted to the subtree starting from the closest parent containing a
parent containing a ``<package>.opam`` file, or the whole ``<package>.opam`` file, or the whole workspace if no such directory exist.
workspace if no such directory exist. Moreover, a subtree Moreover, a subtree containing ``<package>.opam`` doesn' t inherit the
containing ``<package>.opam`` doesn' t inherit the internal internal names available in its parent scope.
names available in its parent scope.
The idea behing this rule is that public library names must be The idea behing this rule is that public library names must be universally
universally unique, but internal ones don't need to. In unique, but internal ones don't need to. In particular you might have private
particular you might have private libraries that are only used libraries that are only used for tests or building an executable.
for tests or building an executable.
As a result, when you create a workspace including several As a result, when you create a workspace including several projects there
projects there might be a name clash between internal library might be a name clash between internal library names.
names.
This scoping rule ensure that this won't be a problem. This scoping rule ensure that this won't be a problem.
.. _alternative-deps:
#. Alternative dependencies #. Alternative dependencies
In addition to direct dependencies you can specify alternative In addition to direct dependencies you can specify alternative dependencies.
dependencies. This is described in the *alternative This is described in the :ref:`Alternative dependencies <alternative-deps>`
dependencies section* section
It is sometimes the case that one wants to not depend on a It is sometimes the case that one wants to not depend on a specific library,
specific library, but instead on whatever is already installed. but instead on whatever is already installed. For instance to use a different
For instance to use a different backend depending on the backend depending on the target.
target.
Jbuilder allows this by using a ``(select ... from ...)`` form Jbuilder allows this by using a ``(select ... from ...)`` form inside the
inside the list of library dependencies. list of library dependencies.
Select forms are specified as follows: Select forms are specified as follows:
@ -610,12 +603,11 @@ doesn't use the ``-pp`` or ``-ppx`` of the various OCaml tools.
#. Preprocessing with actions #. Preprocessing with actions
``<action>`` uses the same DSL as described in the *user ``<action>`` uses the same DSL as described in the `User actions`_ section,
actions section*, and for the same reason given in that and for the same reason given in that section, it will be executed from the
section, it will be executed from the root of the current build root of the current build context. It is expected to be an action that reads
context. It is expected to be an action that reads the file the file given as only dependency and outputs the preprocessed file on its
given as only dependency and outputs the preprocessed file on standard output.
its standard output.
More precisely, ``(preprocess (action <action>))`` acts as if More precisely, ``(preprocess (action <action>))`` acts as if
you had setup a rule for every file of the form: you had setup a rule for every file of the form:
@ -645,22 +637,19 @@ doesn't use the ``-pp`` or ``-ppx`` of the various OCaml tools.
The list of libraries will be ``ppx1`` and ``ppx2`` and the The list of libraries will be ``ppx1`` and ``ppx2`` and the
command line arguments will be: ``-foo -bar 42``. command line arguments will be: ``-foo -bar 42``.
Libraries listed here should be libraries implementing an OCaml Libraries listed here should be libraries implementing an OCaml AST rewriter
AST rewriter and registering themselves using the and registering themselves using the `ocaml-migrate-parsetree.driver API
`ocaml-migrate-parsetree.driver <https://github.com/let-def/ocaml-migrate-parsetree>`__.
API <https://github.com/let-def/ocaml-migrate-parsetree>`__.
Jbuilder will build a single executable by linking all these Jbuilder will build a single executable by linking all these libraries and
libraries and their dependencies. Note that it is important their dependencies. Note that it is important that all these libraries are
that all these libraries are linked with ``-linkall``. Jbuilder linked with ``-linkall``. Jbuilder automatically uses ``-linkall`` when the
automatically uses ``-linkall`` when the ``(kind ...)`` field ``(kind ...)`` field is set to ``ppx_rewriter`` or ``ppx_deriver``.
is set to ``ppx_rewriter`` or ``ppx_deriver``.
It is guaranteed that the last library in the list will be It is guaranteed that the last library in the list will be linked last. You
linked last. You can use this feature to use a custom ppx can use this feature to use a custom ppx driver. By default Jbuilder will use
driver. By default Jbuilder will use ``ocaml-migrate-parsetree.driver-main``. See the section about
``ocaml-migrate-parsetree.driver-main``. See the *section about :ref:`custom-driver` for more details.
using a custom ppx driver* for more details.
#. Per module preprocessing specification #. Per module preprocessing specification
@ -696,16 +685,17 @@ Dependency specification
Dependencies in ``jbuild`` files can be specified using one of the Dependencies in ``jbuild`` files can be specified using one of the
following syntax: following syntax:
- ``(file <filename>)`` or simply ``<filename>``: depend on this - ``(file <filename>)`` or simply ``<filename>``: depend on this file
file - ``(alias <alias-name>)``: depend on the construction of this alias, for
- ``(alias <alias-name>)``: depend on the construction of this instance: ``(alias src/runtest)``
alias, for instance: ``(alias src/runtest)`` - ``(glob_files <glob>)``: depend on all files matched by ``<glob>``, see the
- ``(glob_files <glob>)``: depend on all files matched by :ref:`glob <glob>` for details
``<glob>``, see the *glob section* for details - ``(files_recursively_in <dir>)``: depend on all files in the subtree with root
- ``(files_recursively_in <dir>)``: depend on all files in the ``<dir>``
subtree with root ``<dir>``
In all these cases, the argument supports *variables expansion*. In all these cases, the argument supports `Variables expansion`_.
.. _glob:
#. Glob #. Glob
@ -752,8 +742,7 @@ compilation flags using the following fields:
- ``(ocamlopt_flags <flags>)`` to specify flags passed to - ``(ocamlopt_flags <flags>)`` to specify flags passed to
``ocamlopt`` only ``ocamlopt`` only
For all these fields, ``<flags>`` is specified in the *ordered set For all these fields, ``<flags>`` is specified in the `Ordered set language`_.
language*.
The default value for ``(flags ...)`` includes some ``-w`` options The default value for ``(flags ...)`` includes some ``-w`` options
to set warnings. The exact set depends on whether ``--dev`` is to set warnings. The exact set depends on whether ``--dev`` is
@ -764,6 +753,8 @@ passed to Jbuilder. As a result it is recommended to write
(flags (:standard <my options>)) (flags (:standard <my options>))
.. _jbuild-jsoo:
js_of_ocaml js_of_ocaml
----------- -----------
@ -777,7 +768,7 @@ using ``(js_of_ocaml (<js_of_ocaml-options>))``.
- ``(javascript_files (<files-list>))`` to specify ``js_of_ocaml`` JavaScript - ``(javascript_files (<files-list>))`` to specify ``js_of_ocaml`` JavaScript
runtime files. runtime files.
=<flags>= is specified in the *ordered set language*. =<flags>= is specified in the `Ordered set language`_.
The default value for ``(flags ...)`` depends on whether ``--dev`` is passed to The default value for ``(flags ...)`` depends on whether ``--dev`` is passed to
Jbuilder. ``--dev`` will enable sourcemap and the pretty JavaScript output. Jbuilder. ``--dev`` will enable sourcemap and the pretty JavaScript output.
@ -793,7 +784,7 @@ context as the jbuild they are defined in. So for instance an action defined in
The argument of ``(action ...)`` fields is a small DSL that is interpreted by The argument of ``(action ...)`` fields is a small DSL that is interpreted by
jbuilder directly and doesn't require an external shell. All atoms in the DSL jbuilder directly and doesn't require an external shell. All atoms in the DSL
support *variables expansion*. Moreover, you don't need to specify dependencies support `Variables expansion`_. Moreover, you don't need to specify dependencies
explicitly for the special ``${<kind>:...}`` forms, these are recognized and explicitly for the special ``${<kind>:...}`` forms, these are recognized and
automatically handled by Jbuilder. automatically handled by Jbuilder.
@ -871,6 +862,8 @@ of your project. What you should write instead is:
(deps (blah.mll)) (deps (blah.mll))
(action (chdir ${ROOT} (run ocamllex -o ${@} ${<}))))) (action (chdir ${ROOT} (run ocamllex -o ${@} ${<})))))
.. _ocaml-syntax:
OCaml syntax OCaml syntax
============ ============

6
doc/project-layout-specification.rst
View File

@ -37,7 +37,9 @@ documentation of the `parsexp <https://github.com/janestreet/parsexp>`__
library. library.
Note that the format is completely static. However you can do Note that the format is completely static. However you can do
meta-programming on jbuilds files by writing them in *OCaml syntax*. meta-programming on jbuilds files by writing them in :ref:`ocaml-syntax`.
.. _opam-files:
<package>.opam files <package>.opam files
==================== ====================
@ -92,7 +94,7 @@ If the version can't be determined, Jbuilder just won't assign one.
Note that if you are using `Topkg <https://github.com/dbuenzli/topkg>`__ Note that if you are using `Topkg <https://github.com/dbuenzli/topkg>`__
as well in your project, you shouldn't manually set a version in your as well in your project, you shouldn't manually set a version in your
``<package>.opam`` file or write/generate on of the file listed above. ``<package>.opam`` file or write/generate on of the file listed above.
See *the section about using topkg with jbuilder* for more details. See the section about :ref:`using-topkg` for more details.
Odig conventions Odig conventions
---------------- ----------------

4
doc/terminology.rst
View File

@ -12,7 +12,7 @@ Terminology
things. Jbuilder knows how to build targets that are descendents of things. Jbuilder knows how to build targets that are descendents of
the root. Anything outside of the tree starting from the root is the root. Anything outside of the tree starting from the root is
considered part of the **installed world**. How the root is considered part of the **installed world**. How the root is
determined is explained in *this section*. determined is explained in :ref:`finding-root`.
- **workspace**: the workspace is the subtree starting from the root. - **workspace**: the workspace is the subtree starting from the root.
It can contain any number of projects that will be built It can contain any number of projects that will be built
@ -27,7 +27,7 @@ Terminology
specific configuration from the user, there is always a ``default`` specific configuration from the user, there is always a ``default``
build context, which corresponds to the environment in which Jbuilder build context, which corresponds to the environment in which Jbuilder
is executed. Build contexts can be specified by writing a is executed. Build contexts can be specified by writing a
*jbuild-workspace* file :ref:`jbuild-workspace` file
- **build context root**: the root of a build context named ``foo`` is - **build context root**: the root of a build context named ``foo`` is
``<root>/_build/<foo>`` ``<root>/_build/<foo>``

20
doc/usage.rst
View File

@ -4,9 +4,13 @@ Usage
This section describe usage of Jbuilder from the shell. This section describe usage of Jbuilder from the shell.
.. _finding-root:
Finding the root Finding the root
================ ================
.. _jbuild-workspace:
jbuild-workspace jbuild-workspace
---------------- ----------------
@ -36,10 +40,10 @@ The first entry to match in this list will determine the root. In
practice this means that if you nest your workspaces, Jbuilder will practice this means that if you nest your workspaces, Jbuilder will
always use the outermost one. always use the outermost one.
In addition to determining the root, ``jbuilder`` will read this file as In addition to determining the root, ``jbuilder`` will read this file as to
to setup the configuration of the workspace unless the ``--workspace`` setup the configuration of the workspace unless the ``--workspace`` command line
command line option is used. See the *section about workspace option is used. See the section `Workspace configuration`_ for the syntax of
configuration* for the syntax of this file. this file.
jbuild-workspace\* jbuild-workspace\*
------------------ ------------------
@ -152,6 +156,8 @@ determined as follow:
``../lib`` to it. For instance if ``ocamlc`` is found in ``../lib`` to it. For instance if ``ocamlc`` is found in
``/usr/bin``, use ``/usr/lib`` ``/usr/bin``, use ``/usr/lib``
.. _running-tests:
Running tests Running tests
------------- -------------
@ -335,8 +341,10 @@ It supports two modes of compilation:
The separate compilation mode will be selected when passing ``--dev`` to The separate compilation mode will be selected when passing ``--dev`` to
jbuilder. There is currently no other way to control this behaviour. jbuilder. There is currently no other way to control this behaviour.
See the *section about js_of_ocalm* for passing custom flags to the js_of_ocaml See the section about :ref:`jbuild-jsoo` for passing custom flags to the
compiler js_of_ocaml compiler
.. _using-topkg:
Using topkg with jbuilder Using topkg with jbuilder
========================= =========================