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

fix README.md 

Two things:
1.  `[relative-path]()` does not work with Github markdown (see: [src/]()), you have to write `[relative-path](relative-path)]` (see: [src/](src/)). (`[relative-path][]` and `<relative-path>` don't work either).
2. places using the org-mode syntax `=foo=` where fixed to use backticks instead
This commit is contained in:
Gabriel Scherer 2017-06-08 20:50:58 -04:00 committed by Rudi Grinberg
parent aed36a76dd
commit 06a179df99
1 changed files with 24 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
README.md
View File

@ -168,10 +168,9 @@ there only for convenience, for the following reasons:
### How to add a configure step to a jbuilder project? ### How to add a configure step to a jbuilder project?
[example/sample-projects/with-configure-step]() shows one way to do it [example/sample-projects/with-configure-step](example/sample-projects/with-configure-step) shows
that preserves composability; i.e. it doesn't require to manually run one way to do it which preserves composability; i.e. it doesn't require manually
all `./configure` script when working on multiple projects at the same running `./configure` script when working on multiple projects at the same time.
time.
### Can I use topkg with jbuilder? ### Can I use topkg with jbuilder?
@ -248,14 +247,14 @@ This section is for people who want to work on Jbuilder itself.
### Bootstrap ### Bootstrap
In order to build itself, Jbuilder uses an OCaml script In order to build itself, Jbuilder uses an OCaml script
([bootstrap.ml]()) that dumps most of the sources of Jbuilder into a ([bootstrap.ml](bootstrap.ml)) that dumps most of the sources of Jbuilder into a
single =boot.ml= file. This file is built using =ocamlopt= or =ocamlc= single `boot.ml` file. This file is built using `ocamlopt` or `ocamlc`
and used to build everything else. and used to build everything else.
### OCaml compatibility test ### OCaml compatibility test
Install opam switches for all the entries in the Install opam switches for all the entries in the
[jbuild-workspace.dev]() file and run: [jbuild-workspace.dev](jbuild-workspace.dev) file and run:
```sh ```sh
$ make all-supported-ocaml-versions $ make all-supported-ocaml-versions
@ -263,13 +262,13 @@ $ make all-supported-ocaml-versions
### Repository organization ### Repository organization
- =vendor/= contains dependencies of Jbuilder, that have been vendored - `vendor/` contains dependencies of Jbuilder, that have been vendored
- =plugin/= contains the API given to =jbuild= files that are OCaml - `plugin/` contains the API given to `jbuild` files that are OCaml
scripts scripts
- =src/= contains the core of =Jbuilder=, as a library so that it can - `src/` contains the core of `Jbuilder`, as a library so that it can
be used to implement the Jenga bridge later be used to implement the Jenga bridge later
- =bin/= contains the command line interface - `bin/` contains the command line interface
- =doc/= contains the manual and rules to generate the manual pages - `doc/` contains the manual and rules to generate the manual pages
### Design ### Design
@ -280,23 +279,26 @@ still successfully used for this purpose.
One necessary feature to achieve this is the ability to precisely One necessary feature to achieve this is the ability to precisely
report the external dependencies necessary to build a given set of report the external dependencies necessary to build a given set of
targets without running any command, just by looking at the source targets without running any command, just by looking at the source
tree. This is used to automatically generate the =<package>.opam= tree. This is used to automatically generate the `<package>.opam`
files for all Jane Street packages. files for all Jane Street packages.
To implement this, the build rules are described using a build arrow, To implement this, the build rules are described using a build arrow,
which is defined in [src/build.mli](). In the end it makes the which is defined in [src/build.mli](src/build.mli). In the end it makes the
development of the internal rules of Jbuilder very composable and development of the internal rules of Jbuilder very composable and
quite pleasant. quite pleasant.
To deal with process multiplexing, Jbuilder uses a simplified To deal with process multiplexing, Jbuilder uses a simplified
Lwt/Async-like monad, implemented in [src/future.mli](). Lwt/Async-like monad, implemented in [src/future.mli](src/future.mli).
#### Code flow #### Code flow
- [src/jbuild.mli]() contains the internal representation of `jbuild` - [src/jbuild.mli](src/jbuild.mli) contains the internal representation
files and the parsing code of `jbuild` files and the parsing code
- [src/jbuild_load.mli]() contains the code to scan a source tree and - [src/jbuild_load.mli](src/jbuild_load.mli) contains the code to scan
build the internal database by reading the =jbuild= files a source tree and build the internal database by reading
- [src/gen_rules.mli]() contains all the build rules of Jbuilder the `jbuild` files
- [src/build_system.mli]() contains a trivial implementation of a Build - [src/gen_rules.mli](src/gen_rules.mli) contains all the build rules
system. This is what Jenga will provide when implementing the bridge of Jbuilder
- [src/build_system.mli](src/build_system.mli) contains a trivial
implementation of a Build system. This is what Jenga will provide
when implementing the bridge