Merge remote-tracking branch 'upstream/master' into lang-enumlang-enum

56 files changed, 2516 insertions, 879 deletions

diff --git a/docs/markdown/Adding-new-projects-to-wrapdb.md b/docs/markdown/Adding-new-projects-to-wrapdb.md
index bbe945d..25fb61c 100644
--- a/docs/markdown/Adding-new-projects-to-wrapdb.md
+++ b/docs/markdown/Adding-new-projects-to-wrapdb.md
@@ -6,14 +6,17 @@
 Each wrap repository has a master branch with only one initial commit and *no* wrap files.
 And that is the only commit ever made on that branch.
 
-For every release of a project a new branch is created. The new branch is named after the 
-the upstream release number (e.g. `1.0.0`). This branch holds a wrap file for 
+For every release of a project a new branch is created. The new branch is named after the
+the upstream release number (e.g. `1.0.0`). This branch holds a wrap file for
 this particular release.
 
 There are two types of wraps on WrapDB - regular wraps and wraps with Meson build
 definition patches. A wrap file in a repository on WrapDB must have a name `upstream.wrap`.
 
-Wraps with Meson build definition patches work in much the same way as Debian: we take the unaltered upstream source package and add a new build system to it as a patch. These build systems are stored as Git repositories on GitHub. They only contain build definition files. You may also think of them as an overlay to upstream source.
+Wraps with Meson build definition patches work in much the same way as Debian:
+we take the unaltered upstream source package and add a new build system to it as a patch.
+These build systems are stored as Git repositories on GitHub. They only contain build definition files.
+You may also think of them as an overlay to upstream source.
 
 Whenever a new commit is pushed into GitHub's project branch, a new wrap is generated
 with an incremented version number. All the old releases remain unaltered.
@@ -21,13 +24,15 @@ New commits are always done via GitHub merge requests and must be reviewed by
 someone other than the submitter.
 
 Note that your Git repo with wrap must not contain the subdirectory of the source
-release. That gets added automatically by the service. You also must not commit 
+release. That gets added automatically by the service. You also must not commit
 any source code from the original tarball into the wrap repository.
 
 ## Choosing the repository name
 
 Wrapped subprojects are used much like external dependencies. Thus
-they should have the same name as the upstream projects. 
+they should have the same name as the upstream projects.
+
+NOTE: Repo names must fully match this regexp: `[a-z0-9._]+`.
 
 If the project provides a pkg-config file, then the repository name should be
 the same as the pkg-config name. Usually this is the name of the
@@ -36,16 +41,19 @@ however. As an example the libogg project's chosen pkg-config name is
 `ogg` instead of `libogg`, which is the reason why the repository is
 named plain `ogg`.
 
-If there is no a pkg-config file, the name the project uses/promotes should be used, 
+If there is no a pkg-config file, the name the project uses/promotes should be used,
 lowercase only (Catch2 -> catch2).
 
+If the project name is too generic or ambiguous (e.g. `benchmark`),
+consider using `organization-project` naming format (e.g. `google-benchmark`).
+
 ## How to contribute a new wrap
 
 If the project already uses Meson build system, then only a wrap file - `upstream.wrap`
-should be provided. In other case a Meson build definition patch - a set of `meson.build` 
+should be provided. In other case a Meson build definition patch - a set of `meson.build`
 files - should be also provided.
 
-### Request a new repository or branch
+### Request a new repository
 
 Create an issue on the [wrapdb bug tracker](https://github.com/mesonbuild/wrapdb/issues)
 using *Title* and *Description* below as a template.
@@ -61,6 +69,9 @@ version: <version_you_have_a_wrap_for>
 Wait until the new repository or branch is created. A link to the new repository or branch
 will be posted in a comment to this issue.
 
+NOTE: Requesting a branch is not necessary. WrapDB maintainer can create the branch and
+modify the PR accordingly if the project repository exists.
+
 ### Add a new wrap
 
 First you need to fork the repository to your own page.
@@ -80,28 +91,28 @@ git commit -a -m 'Add wrap files for libfoo-1.0.0'
 git push origin 1.0.0
 ```
 
-Now you should create a pull request on GitHub. Remember to create it against the 
-correct branch rather than master (`1.0.0` branch in this example). GitHub should do 
+Now you should create a pull request on GitHub. Remember to create it against the
+correct branch rather than master (`1.0.0` branch in this example). GitHub should do
 this automatically.
 
+If the branch doesn't exist file a pull request against master.
+WrapDB maintainers can fix it before merging.
+
 ## What is done by WrapDB maintainers
 
+[mesonwrap tools](Wrap-maintainer-tools.md) must be used for the tasks below.
+
 ### Adding new project to the Wrap provider service
 
 Each project gets its own repo. It is initialized like this:
 
 ```
-git init
-git add readme.txt
-git add LICENSE.build
-git commit -a -m 'Create project foobar'
-git remote add origin <repo url>
-git push -u origin master
+mesonwrap new_repo --homepage=$HOMEPAGE --directory=$NEW_LOCAL_PROJECT_DIR $PROJECT_NAME
 ```
 
-Note that this is the *only* commit that will ever be made to master branch. All other commits are done to branches.
+The command creates a new repository and uploads it to Github.
 
-Repo names must fully match this regexp: `[a-z0-9._]+`.
+`--version` flag may be used to create a branch immediately.
 
 ### Adding a new branch to an existing project
 
@@ -129,12 +140,6 @@ to functionality. All such changes must be submitted to upstream. You
 may also host your own Git repo with the changes if you wish. The Wrap
 system has native support for Git subprojects.
 
-## Creator script
-
-The WrapDB repository has a
-[helper script](https://github.com/mesonbuild/mesonwrap/blob/master/mesonwrap.py)
-to generate new repositories, verify them and update them.
-
 ## Reviewing wraps
 
 See [Wrap review guidelines](Wrap-review-guidelines.md).
diff --git a/docs/markdown/Build-options.md b/docs/markdown/Build-options.md
index 2d53e28..429b9b2 100644
--- a/docs/markdown/Build-options.md
+++ b/docs/markdown/Build-options.md
@@ -20,6 +20,9 @@ option('integer_opt', type : 'integer', min : 0, max : 5, value : 3) # Since 0.4
 option('free_array_opt', type : 'array', value : ['one', 'two'])  # Since 0.44.0
 option('array_opt', type : 'array', choices : ['one', 'two', 'three'], value : ['one', 'two'])
 option('some_feature', type : 'feature', value : 'enabled')  # Since 0.47.0
+option('long_desc', type : 'string', value : 'optval',
+       description : 'An option with a very long description' +
+                     'that does something in a specific context') # Since 0.55.0
 ```
 
 For built-in options, see [Built-in options][builtin_opts].
diff --git a/docs/markdown/Builtin-options.md b/docs/markdown/Builtin-options.md
index aa7d500..de801ab 100644
--- a/docs/markdown/Builtin-options.md
+++ b/docs/markdown/Builtin-options.md
@@ -17,7 +17,7 @@ by setting them inside `default_options` of `project()` in your `meson.build`.
 
 For legacy reasons `--warnlevel` is the cli argument for the `warning_level` option.
 
-They can also be edited after setup using `meson configure`.
+They can also be edited after setup using `meson configure -Doption=value`.
 
 Installation options are all relative to the prefix, except:
 
@@ -55,37 +55,31 @@ particularly the paths section may be necessary.
 
 ### Core options
 
-Options that are labeled "per machine" in the table are set per machine.
-Prefixing the option with `build.` just affects the build machine configuration,
-while unprefixed just affects the host machine configuration, respectively.
-Using the option as-is with no prefix affects all machines. For example:
-
- - `build.pkg_config_path` controls the paths pkg-config will search for just
-   `native: true` dependencies (build machine).
-
- - `pkg_config_path` controls the paths pkg-config will search for just
-   `native: false` dependencies (host machine).
-
-| Option                               | Default value | Description                                                    | Is per machine |
-| ------                               | ------------- | -----------                                                    | -------------- |
-| auto_features {enabled, disabled, auto} | auto       | Override value of all 'auto' features                          | no             |
-| backend {ninja, vs,<br>vs2010, vs2015, vs2017, vs2019, xcode} | ninja | Backend to use                                | no             |
-| buildtype {plain, debug,<br>debugoptimized, release, minsize, custom} | debug |  Build type to use                    | no             |
-| debug                                | true          | Debug                                                          | no             |
-| default_library {shared, static, both} | shared      | Default library type                                           | no             |
-| errorlogs                            | true          | Whether to print the logs from failing tests.                  | no             |
-| install_umask {preserve, 0000-0777}  | 022           | Default umask to apply on permissions of installed files       | no             |
-| layout {mirror,flat}                 | mirror        | Build directory layout                                         | no             |
-| optimization {0, g, 1, 2, 3, s}      | 0             | Optimization level                                             | no             |
-| pkg_config_path {OS separated path}  | ''            | Additional paths for pkg-config to search before builtin paths | yes            |
-| cmake_prefix_path                    | []            | Additional prefixes for cmake to search before builtin paths   | yes            |
-| stdsplit                             | true          | Split stdout and stderr in test logs                           | no             |
-| strip                                | false         | Strip targets on install                                       | no             |
-| unity {on, off, subprojects}         | off           | Unity build                                                    | no             |
-| unity_size {>=2}                     | 4             | Unity file block size                                          | no             |
-| warning_level {0, 1, 2, 3}           | 1             | Set the warning level. From 0 = none to 3 = highest            | no             |
-| werror                               | false         | Treat warnings as errors                                       | no             |
-| wrap_mode {default, nofallback,<br>nodownload, forcefallback} | default | Wrap mode to use                            | no             |
+Options that are labeled "per machine" in the table are set per machine. See
+the [specifying options per machine](#Specifying-options-per-machine) section
+for details.
+
+| Option                               | Default value | Description                                                    | Is per machine | Is per subproject |
+| ------                               | ------------- | -----------                                                    | -------------- | ----------------- |
+| auto_features {enabled, disabled, auto} | auto       | Override value of all 'auto' features                          | no             | no                |
+| backend {ninja, vs,<br>vs2010, vs2015, vs2017, vs2019, xcode} | ninja | Backend to use                                | no             | no                |
+| buildtype {plain, debug,<br>debugoptimized, release, minsize, custom} | debug |  Build type to use                    | no             | no                |
+| debug                                | true          | Debug                                                          | no             | no                |
+| default_library {shared, static, both} | shared      | Default library type                                           | no             | yes               |
+| errorlogs                            | true          | Whether to print the logs from failing tests.                  | no             | no                |
+| install_umask {preserve, 0000-0777}  | 022           | Default umask to apply on permissions of installed files       | no             | no                |
+| layout {mirror,flat}                 | mirror        | Build directory layout                                         | no             | no                |
+| optimization {0, g, 1, 2, 3, s}      | 0             | Optimization level                                             | no             | no                |
+| pkg_config_path {OS separated path}  | ''            | Additional paths for pkg-config to search before builtin paths | yes            | no                |
+| cmake_prefix_path                    | []            | Additional prefixes for cmake to search before builtin paths   | yes            | no                |
+| stdsplit                             | true          | Split stdout and stderr in test logs                           | no             | no                |
+| strip                                | false         | Strip targets on install                                       | no             | no                |
+| unity {on, off, subprojects}         | off           | Unity build                                                    | no             | no                |
+| unity_size {>=2}                     | 4             | Unity file block size                                          | no             | no                |
+| warning_level {0, 1, 2, 3}           | 1             | Set the warning level. From 0 = none to 3 = highest            | no             | yes               |
+| werror                               | false         | Treat warnings as errors                                       | no             | yes               |
+| wrap_mode {default, nofallback,<br>nodownload, forcefallback} | default | Wrap mode to use                            | no             | no                |
+| force_fallback_for                   | []            | Force fallback for those dependencies                          | no             | no                |
 
 <a name="build-type-options"></a>
 For setting optimization levels and toggling debug, you can either set the
@@ -186,9 +180,9 @@ The default values of `c_winlibs` and `cpp_winlibs` are in compiler-specific
 argument forms, but the libraries are: kernel32, user32, gdi32, winspool,
 shell32, ole32, oleaut32, uuid, comdlg32, advapi32.
 
-c_args, cpp_args, c_link_args, and cpp_link_args only affect native builds,
-when cross compiling they will not be applied to binaries or libraries
-targeting the host system, only those being run on the build system.
+All these `<lang>_*` options are specified per machine. See below in the
+[specifying options per machine](#Specifying-options-per-machine) section on
+how to do this in cross builds.
 
 When using MSVC, `cpp_eh=none` will result in no exception flags being passed,
 while the `cpp_eh=[value]` will result in `/EH[value]`.
@@ -199,3 +193,44 @@ gcc-style compilers, nothing is passed (allowing exceptions to work), while
 Since *0.54.0* The `<lang>_thread_count` option can be used to control the
 value passed to `-s PTHREAD_POOL_SIZE` when using emcc. No other c/c++
 compiler supports this option.
+
+## Specifying options per machine
+
+Since *0.51.0*, some options are specified per machine rather than globally for
+all machine configurations. Prefixing the option with `build.` just affects the
+build machine configuration, while unprefixed just affects the host machine
+configuration, respectively. For example:
+
+ - `build.pkg_config_path` controls the paths pkg-config will search for just
+   `native: true` dependencies (build machine).
+
+ - `pkg_config_path` controls the paths pkg-config will search for just
+   `native: false` dependencies (host machine).
+
+This is useful for cross builds. In the native builds, build = host, and the
+unprefixed option alone will suffice.
+
+Prior to *0.51.0*, these options just effected native builds when specified on
+the command line, as there was no `build.` prefix. Similarly named fields in
+the `[properties]` section of the cross file would effect cross compilers, but
+the code paths were fairly different allowing differences in behavior to crop
+out.
+
+## Specifying options per subproject
+
+Since *0.54.0* `default_library` and `werror` built-in options can be defined
+per subproject. This is useful for example when building shared libraries in the
+main project, but static link a subproject, or when the main project must build
+with no warnings but some subprojects cannot.
+
+Most of the time this would be used either by the parent project by setting
+subproject's default_options (e.g. `subproject('foo', default_options: 'default_library=static')`),
+or by the user using the command line `-Dfoo:default_library=static`.
+
+The value is overriden in this order:
+- Value from parent project
+- Value from subproject's default_options if set
+- Value from subproject() default_options if set
+- Value from command line if set
+
+Since 0.56.0 `warning_level` can also be defined per subproject.
diff --git a/docs/markdown/CMake-module.md b/docs/markdown/CMake-module.md
index 7103608..fc6157e 100644
--- a/docs/markdown/CMake-module.md
+++ b/docs/markdown/CMake-module.md
@@ -48,8 +48,6 @@ The `subproject` method is almost identical to the normal meson
 `subproject` function. The only difference is that a CMake project
 instead of a meson project is configured.
 
-Also, project specific CMake options can be added with the `cmake_options` key.
-
 The returned `sub_proj` supports the same options as a "normal" subproject.
 Meson automatically detects CMake build targets, which can be accessed with
 the methods listed [below](#subproject-object).
@@ -87,6 +85,49 @@ It should be noted that not all projects are guaranteed to work. The
 safest approach would still be to create a `meson.build` for the
 subprojects in question.
 
+### Configuration options
+
+*New in meson 0.55.0*
+
+Meson also supports passing configuration options to CMake and overriding
+certain build details extracted from the CMake subproject.
+
+```meson
+cmake   = import('cmake')
+opt_var = cmake.subproject_options()
+
+# Call CMake with `-DSOME_OTHER_VAR=ON`
+opt_var.add_cmake_defines({'SOME_OTHER_VAR': true})
+
+# Globally override the C++ standard to c++11
+opt_var.set_override_option('cpp_std', 'c++11')
+
+# Override the previous global C++ standard
+# with c++14 only for the CMake target someLib
+opt_var.set_override_option('cpp_std', 'c++14', target: 'someLib')
+
+sub_pro = cmake.subproject('someLibProject', options: opt_var)
+
+# Further changes to opt_var have no effect
+```
+
+See [the CMake options object](#cmake-options-object) for a complete reference
+of all supported functions.
+
+The CMake configuration options object is very similar to the
+[configuration data object](Reference-manual.md#configuration-data-object) object
+returned by [`configuration_data`](Reference-manual.md#configuration_data). It
+is generated by the `subproject_options` function
+
+All configuration options have to be set *before* the subproject is configured
+and must be passed to the `subproject` method via the `options` key. Altering
+the configuration object won't have any effect on previous `cmake.subproject`
+calls.
+
+In earlier meson versions CMake command-line parameters could be set with the
+`cmake_options` kwarg. However, this feature is deprecated since 0.55.0 and only
+kept for compatibility. It will not work together with the `options` kwarg.
+
 ### `subproject` object
 
 This object is returned by the `subproject` function described above
@@ -103,7 +144,37 @@ and supports the following methods:
    the subproject. Usually `dependency()` or `target()` should be
    preferred to extract build targets.
  - `found` returns true if the subproject is available, otherwise false
-   *new in in 0.53.2*
+   *new in meson 0.53.2*
+
+### `cmake options` object
+
+This object is returned by the `subproject_options()` function and consumed by
+the `options` kwarg of the `subproject` function. The following methods are
+supported:
+
+ - `add_cmake_defines({'opt1': val1, ...})` add additional CMake commandline defines
+ - `set_override_option(opt, val)` set specific [build options](Build-options.md)
+   for targets. This will effectively add `opt=val` to the `override_options`
+   array of the [build target](Reference-manual.md#executable)
+ - `set_install(bool)` override wether targets should be installed or not
+ - `append_compile_args(lang, arg1, ...)` append compile flags for a specific
+   language to the targets
+ - `append_link_args(arg1, ...)` append linger args to the targets
+ - `clear()` reset all data in the `cmake options` object
+
+The methods `set_override_option`, `set_install`, `append_compile_args` and
+`append_link_args` support the optional `target` kwarg. If specified, the set
+options affect the specific target. The effect of the option is global for the
+subproject otherwise.
+
+If, for instance, `opt_var.set_install(false)` is called, no target will be
+installed regardless of what is set by CMake. However, it is still possible to
+install specific targets (here `foo`) by setting the `target` kwarg:
+`opt_var.set_install(true, target: 'foo')`
+
+Options that are not set won't affect the generated subproject. So, if for
+instance, `set_install` was not called then the values extracted from CMake will
+be used.
 
 ## CMake configuration files
 
diff --git a/docs/markdown/Configuring-a-build-directory.md b/docs/markdown/Configuring-a-build-directory.md
index 1387a46..330899f 100644
--- a/docs/markdown/Configuring-a-build-directory.md
+++ b/docs/markdown/Configuring-a-build-directory.md
@@ -109,11 +109,11 @@ you would issue the following command.
 
     meson configure -Dprefix=/tmp/testroot
 
-Then you would run your build command (usually `ninja`), which would
+Then you would run your build command (usually `meson compile`), which would
 cause Meson to detect that the build setup has changed and do all the
 work required to bring your build tree up to date.
 
 Since 0.50.0, it is also possible to get a list of all build options
-by invoking `meson configure` with the project source directory or
+by invoking [`meson configure`](Commands.md#configure) with the project source directory or
 the path to the root `meson.build`. In this case, meson will print the
 default values of all options similar to the example output from above.
diff --git a/docs/markdown/Continuous-Integration.md b/docs/markdown/Continuous-Integration.md
index 0846f2d..76a05a3 100644
--- a/docs/markdown/Continuous-Integration.md
+++ b/docs/markdown/Continuous-Integration.md
@@ -36,8 +36,8 @@ script:
   - if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then echo FROM YOUR/REPO:eoan > Dockerfile; fi
   - if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then echo ADD . /root >> Dockerfile; fi
   - if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then docker build -t withgit .; fi
-  - if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then docker run withgit /bin/sh -c "cd /root && TRAVIS=true CC=$CC CXX=$CXX meson builddir && ninja -C builddir test"; fi
-  - if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then SDKROOT=$(xcodebuild -version -sdk macosx Path) meson builddir && ninja -C builddir test; fi
+  - if [[ "$TRAVIS_OS_NAME" == "linux" ]]; then docker run withgit /bin/sh -c "cd /root && TRAVIS=true CC=$CC CXX=$CXX meson builddir && meson test -C builddir"; fi
+  - if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then SDKROOT=$(xcodebuild -version -sdk macosx Path) meson builddir && meson test -C builddir; fi
 ```
 
 ## CircleCi for Linux (with Docker)
@@ -69,7 +69,7 @@ jobs:
     steps:
       - checkout
       - run: meson setup builddir --backend ninja
-      - run: ninja -C builddir
+      - run: meson compile -C builddir
       - run: meson test -C builddir
 
   meson_debian_build:
@@ -77,7 +77,7 @@ jobs:
     steps:
       - checkout
       - run: meson setup builddir --backend ninja
-      - run: ninja -C builddir
+      - run: meson compile -C builddir
       - run: meson test -C builddir
 
   meson_fedora_build:
@@ -85,7 +85,7 @@ jobs:
     steps:
       - checkout
       - run: meson setup builddir --backend ninja
-      - run: ninja -C builddir
+      - run: meson compile -C builddir
       - run: meson test -C builddir
 
 workflows:
@@ -138,10 +138,10 @@ install:
 build_script:
   - cmd: echo Building on %arch% with %compiler%
   - cmd: meson --backend=ninja builddir
-  - cmd: ninja -C builddir
+  - cmd: meson compile -C builddir
 
 test_script:
-  - cmd: ninja -C builddir test
+  - cmd: meson test -C builddir
 ```
 
 ### Qt
@@ -187,8 +187,8 @@ install:
 
 script:
   - meson builddir
-  - ninja -C builddir
-  - ninja -C builddir test
+  - meson compile -C builddir
+  - meson test -C builddir
 ```
 
 ## GitHub Actions
diff --git a/docs/markdown/Contributing.md b/docs/markdown/Contributing.md
index 5332938..b16f615 100644
--- a/docs/markdown/Contributing.md
+++ b/docs/markdown/Contributing.md
@@ -174,7 +174,7 @@ contents of an additional file into the CI log on failure.
 Projects needed by unit tests are in the `test cases/unit`
 subdirectory. They are not run as part of `./run_project_tests.py`.
 
-#### Configuring project tests
+### Configuring project tests
 
 The (optional) `test.json` file, in the root of a test case, is used
 for configuring the test. All of the following root entries in the `test.json`
@@ -209,17 +209,20 @@ Exanple `test.json`:
       { "opt1": "qwert", "opt2": "false" },
       { "opt1": "bad"                    }
     ]
+  },
+  "tools": {
+    "cmake": ">=3.11"
   }
 }
 ```
 
-##### env
+#### env
 
 The `env` key contains a dictionary which specifies additional
 environment variables to be set during the configure step of the test. `@ROOT@`
 is replaced with the absolute path of the source directory.
 
-##### installed
+#### installed
 
 The `installed` dict contains a list of dicts, describing which files are expected
 to be installed. Each dict contains the following keys:
@@ -277,7 +280,7 @@ the platform matches. The following values for `platform` are currently supporte
 | `cygwin`   | Matches when the platform is cygwin                                  |
 | `!cygwin`  | Not `cygwin`                                                         |
 
-##### matrix
+#### matrix
 
 The `matrix` section can be used to define a test matrix to run project tests
 with different meson options.
@@ -318,12 +321,40 @@ The above example will produce the following matrix entries:
 - `opt1=qwert`
 - `opt1=qwert opt2=true`
 
-##### do_not_set_opts
+#### do_not_set_opts
 
 Currently supported values are:
 - `prefix`
 - `libdir`
 
+#### tools
+
+This section specifies a dict of tool requirements in a simple key-value format.
+If a tool is specified, it has to be present in the environment, and the version
+requirement must be fulfilled. Otherwise, the entire test is skipped (including
+every element in the test matrix).
+
+#### stdout
+
+The `stdout` key contains a list of dicts, describing the expected stdout.
+
+Each dict contains the following keys:
+
+- `line`
+- `match` (optional)
+
+Each item in the list is matched, in order, against the remaining actual stdout
+lines, after any previous matches. If the actual stdout is exhausted before
+every item in the list is matched, the expected output has not been seen, and
+the test has failed.
+
+The `match` element of the dict determines how the `line` element is matched:
+
+| Type      | Description             |
+| --------  | ----------------------- |
+| `literal` | Literal match (default) |
+| `re`      | regex match             |
+
 ### Skipping integration tests
 
 Meson uses several continuous integration testing systems that have slightly
diff --git a/docs/markdown/Creating-OSX-packages.md b/docs/markdown/Creating-OSX-packages.md
index bda06a3..849d5fd 100644
--- a/docs/markdown/Creating-OSX-packages.md
+++ b/docs/markdown/Creating-OSX-packages.md
@@ -39,7 +39,7 @@ $ meson --prefix=/tmp/myapp.app \
         <other flags you might need>
 ```
 
-Now when we do `ninja install` the bundle is properly staged. If you
+Now when we do `meson install` the bundle is properly staged. If you
 have any resource files or data, you need to install them into
 `Contents/Resources` either by custom install commands or specifying
 more install paths to the Meson command.
diff --git a/docs/markdown/Creating-releases.md b/docs/markdown/Creating-releases.md
index 45c4b4e..040fb53 100644
--- a/docs/markdown/Creating-releases.md
+++ b/docs/markdown/Creating-releases.md
@@ -5,27 +5,56 @@ short-description: Creating releases
 # Creating releases
 
 In addition to development, almost all projects provide periodical
-source releases. These are standalone packages (usually either in tar
-or zip format) of the source code. They do not contain any revision
-control metadata, only the source code.
+source releases. These are standalone packages (usually either in
+tar or zip format) of the source code. They do not contain any
+revision control metadata, only the source code.  Meson provides
+a simple way of generating these, with the `meson dist` command.
 
 Meson provides a simple way of generating these. It consists of a
-single command:
+single command *(available since 0.52.0)*:
 
-    ninja dist
+```sh
+meson dist
+```
+
+or alternatively (on older meson versions with `ninja` backend):
+
+```sh
+ninja dist
+```
 
 This creates a file called `projectname-version.tar.xz` in the build
-tree subdirectory `meson-dist`. This archive contains the full
-contents of the latest commit in revision control including all the
-submodules (recursively). All revision control metadata is removed.
-Meson then takes
-this archive and tests that it works by doing a full compile + test +
-install cycle. If all these pass, Meson will then create a SHA-256
-checksum file next to the archive.
-
-**Note**: Meson behaviour is different from Autotools. The Autotools
-"dist" target packages up the current source tree. Meson packages
-the latest revision control commit. The reason for this is that it
-prevents developers from doing accidental releases where the
-distributed archive does not match any commit in revision control
-(especially the one tagged for the release).
+tree subdirectory `meson-dist`. This archive contains the full contents
+of the latest commit in revision control including all the submodules
+(recursively). All revision control metadata is removed. Meson then
+takes this archive and tests that it works by doing a full 
+`compile` + `test` + `install` cycle. If all these pass, Meson will
+then create a `SHA-256` checksum file next to the archive.
+
+
+## Autotools dist VS Meson dist
+
+Meson behaviour is different from Autotools. The Autotools "dist"
+target packages up the current source tree. Meson packages the latest
+revision control commit. The reason for this is that it prevents developers
+from doing accidental releases where the distributed archive does not match
+any commit in revision control (especially the one tagged for the release).
+
+
+## Include subprojects in your release
+
+The `meson dist` command has `--include-subprojects` command line option.
+When enabled, the source tree of all subprojects used by the current build
+will also be included in the final tarball. This is useful to distribute
+self contained tarball that can be built offline (i.e. `--wrap-mode=nodownload`).
+
+
+## Skip build and test with `--no-tests`
+
+The `meson dist` command has a `--no-tests` option to skip build and
+tests steps of generated packages. It can be used to not waste time
+for example when done in CI that already does its own testing.
+
+So with `--no-tests` you can tell Meson "Do not build and test generated
+packages.".
+
diff --git a/docs/markdown/Cross-compilation.md b/docs/markdown/Cross-compilation.md
index 4c4b7bf..d86d417 100644
--- a/docs/markdown/Cross-compilation.md
+++ b/docs/markdown/Cross-compilation.md
@@ -222,7 +222,7 @@ Once you have the cross file, starting a build is simple
 $ meson srcdir builddir --cross-file cross_file.txt
 ```
 
-Once configuration is done, compilation is started by invoking Ninja
+Once configuration is done, compilation is started by invoking `meson compile`
 in the usual way.
 
 ## Introspection and system checks
@@ -231,13 +231,10 @@ The main *meson* object provides two functions to determine cross
 compilation status.
 
 ```meson
-meson.is_cross_build()  # returns true when cross compiling
-meson.has_exe_wrapper() # returns true if an exe wrapper has been defined
+meson.is_cross_build()        # returns true when cross compiling
+meson.can_run_host_binaries() # returns true if the host binaries can be run, either with a wrapper or natively
 ```
 
-Note that the latter gives undefined return value when doing a native
-build.
-
 You can run system checks on both the system compiler or the cross
 compiler. You just have to specify which one to use.
 
diff --git a/docs/markdown/Dependencies.md b/docs/markdown/Dependencies.md
index 17c9991..b89a0aa 100644
--- a/docs/markdown/Dependencies.md
+++ b/docs/markdown/Dependencies.md
@@ -76,7 +76,7 @@ and config-tool based variables.
 
 ```meson
 foo_dep = dependency('foo')
-var = foo.get_variable(cmake : 'CMAKE_VAR', pkgconfig : 'pkg-config-var', configtool : 'get-var', default_value : 'default')
+var = foo_dep.get_variable(cmake : 'CMAKE_VAR', pkgconfig : 'pkg-config-var', configtool : 'get-var', default_value : 'default')
 ```
 
 It accepts the keywords 'cmake', 'pkgconfig', 'pkgconfig_define',
@@ -242,6 +242,9 @@ libgcrypt_dep = dependency('libgcrypt', version: '>= 1.8')
 gpgme_dep = dependency('gpgme', version: '>= 1.0')
 ```
 
+*Since 0.55.0* Meson won't search $PATH any more for a config tool binary when
+cross compiling if the config tool did not have an entry in the cross file.
+
 ## AppleFrameworks
 
 Use the `modules` keyword to list frameworks required, e.g.
@@ -285,8 +288,12 @@ You can call `dependency` multiple times with different modules and
 use those to link against your targets.
 
 If your boost headers or libraries are in non-standard locations you
-can set the BOOST_ROOT, BOOST_INCLUDEDIR, and/or BOOST_LIBRARYDIR
-environment variables.
+can set the `BOOST_ROOT`, or the `BOOST_INCLUDEDIR` and `BOOST_LIBRARYDIR`
+environment variables. *(added in 0.56.0)* You can also set these
+parameters as `boost_root`, `boost_include`, and `boost_librarydir` in your
+native or cross machine file. Note that machine file variables are
+preferred to environment variables, and that specifying any of these
+disables system-wide search for boost.
 
 You can set the argument `threading` to `single` to use boost
 libraries that have been compiled for single-threaded use instead.
diff --git a/docs/markdown/Design-rationale.md b/docs/markdown/Design-rationale.md
index 57aaee4..7121192 100644
--- a/docs/markdown/Design-rationale.md
+++ b/docs/markdown/Design-rationale.md
@@ -223,11 +223,11 @@ add_test('test library', exe)
 ```
 
 First we build a shared library named foobar. It is marked
-installable, so running `ninja install` installs it to the library
+installable, so running `meson install` installs it to the library
 directory (the system knows which one so the user does not have to
 care). Then we build a test executable which is linked against the
 library. It will not be installed, but instead it is added to the list
-of unit tests, which can be run with the command `ninja test`.
+of unit tests, which can be run with the command `meson test`.
 
 Above we mentioned precompiled headers as a feature not supported by
 other build systems. Here's how you would use them.
diff --git a/docs/markdown/FAQ.md b/docs/markdown/FAQ.md
index e43c857..7a41443 100644
--- a/docs/markdown/FAQ.md
+++ b/docs/markdown/FAQ.md
@@ -51,7 +51,7 @@ $ /path/to/meson.py <options>
 After this you don't have to care about invoking Meson any more. It
 remembers where it was originally invoked from and calls itself
 appropriately. As a user the only thing you need to do is to `cd` into
-your build directory and invoke `ninja`.
+your build directory and invoke `meson compile`.
 
 ## Why can't I specify target files with a wildcard?
 
@@ -432,7 +432,7 @@ sources in the build target:
 libfoo_gen_headers = custom_target('gen-headers', ..., output: 'foo-gen.h')
 libfoo_sources = files('foo-utils.c', 'foo-lib.c')
 # Add generated headers to the list of sources for the build target
-libfoo = library('foo', sources: libfoo_sources + libfoo_gen_headers)
+libfoo = library('foo', sources: [libfoo_sources + libfoo_gen_headers])
 ```
 
 Now let's say you have a new target that links to `libfoo`:
diff --git a/docs/markdown/Feature-autodetection.md b/docs/markdown/Feature-autodetection.md
index c1b7659..4d366d9 100644
--- a/docs/markdown/Feature-autodetection.md
+++ b/docs/markdown/Feature-autodetection.md
@@ -28,12 +28,12 @@ the binaries `gcovr`, `lcov` and `genhtml`. If version 3.3 or higher
 of the first is found, targets called *coverage-text*, *coverage-xml*
 and *coverage-html* are generated. Alternatively, if the latter two
 are found, only the target *coverage-html* is generated. Coverage
-reports can then be produced simply by calling e.g. `ninja
+reports can then be produced simply by calling e.g. `meson compile
 coverage-xml`. As a convenience, a high-level *coverage* target is
 also generated which will produce all 3 coverage report types, if
 possible.
 
 Note that generating any of the coverage reports described above
-requires the tests (i.e. `ninja test`) to finish running so the
+requires the tests (i.e. `meson test`) to finish running so the
 information about the functions that are called in the tests can be
 gathered for the report.
diff --git a/docs/markdown/Gnome-module.md b/docs/markdown/Gnome-module.md
index a9c4531..3d06233 100644
--- a/docs/markdown/Gnome-module.md
+++ b/docs/markdown/Gnome-module.md
@@ -88,7 +88,6 @@ There are several keyword arguments. Many of these map directly to the
   e.g. `Gtk`
 * `includes`: list of gir names to be included, can also be a GirTarget
 * `header`: *(Added 0.43.0)* name of main c header to include for the library, e.g. `glib.h`
-* `dependencies`: deps to use during introspection scanning
 * `include_directories`: extra include paths to look for gir files
 * `install`: if true, install the generated files
 * `install_dir_gir`: (*Added 0.35.0*) which directory to install the
@@ -98,6 +97,7 @@ There are several keyword arguments. Many of these map directly to the
 * `link_with`: list of libraries to link with
 * `symbol_prefix`: the symbol prefix for the gir object, e.g. `gtk`,
   (*Since 0.43.0*) an ordered list of multiple prefixes is allowed
+* `fatal_warnings`: *Since 0.55.0* turn scanner warnings into fatal errors.
 
 Returns an array of two elements which are: `[gir_target,
 typelib_target]`
@@ -223,7 +223,7 @@ directory. Note that this is not for installing schemas and is only
 useful when running the application locally for example during tests.
 
 * `build_by_default`: causes, when set to true, to have this target be
-  built by default, that is, when invoking plain `ninja`, the default
+  built by default, that is, when invoking plain `meson compile`, the default
   value is true for all built target types
 * `depend_files`: files ([`string`](Reference-manual.md#string-object),
   [`files()`](Reference-manual.md#files), or
@@ -246,7 +246,7 @@ one XML file.
 * `annotations`: *(Added 0.43.0)* list of lists of 3 strings for the annotation for `'ELEMENT', 'KEY', 'VALUE'`
 * `docbook`: *(Added 0.43.0)* prefix to generate `'PREFIX'-NAME.xml` docbooks
 * `build_by_default`: causes, when set to true, to have this target be
-  built by default, that is, when invoking plain `ninja`, the default
+  built by default, that is, when invoking plain `meson compile`, the default
   value is true for all built target types
 * `install_dir`: (*Added 0.46.0*) location to install the header or
   bundle depending on previous options
@@ -344,8 +344,8 @@ of the module.
   Note that this has the downside of rebuilding the doc for each build, which is
   often very slow. It usually should be enabled only in CI.
 
-This creates a `$module-doc` target that can be ran to build docs and
-normally these are only built on install.
+This also creates a `$module-doc` target that can be run to build documentation.
+Normally the documentation is only built on install.
 
 *Since 0.52.0* Returns a target object that can be passed as dependency to other
 targets using generated doc files (e.g. in `content_files` of another doc).
diff --git a/docs/markdown/IDE-integration.md b/docs/markdown/IDE-integration.md
index a6c6f4b..ee51b64 100644
--- a/docs/markdown/IDE-integration.md
+++ b/docs/markdown/IDE-integration.md
@@ -25,20 +25,21 @@ With this command meson will configure the project and also generate
 introspection information that is stored in `intro-*.json` files in the
 `meson-info` directory. The introspection dump will be automatically updated
 when meson is (re)configured, or the build options change. Thus, an IDE can
-watch for changes in this directory to know when something changed.
+watch for changes in this directory to know when something changed. Note that
+`meson-info.json` guaranteed to be the last file written.
 
 The `meson-info` directory should contain the following files:
 
-| File                            | Description                                                         |
-| ----                            | -----------                                                         |
-| `intro-benchmarks.json`         | Lists all benchmarks                                                |
-| `intro-buildoptions.json`       | Contains a full list of meson configuration options for the project |
-| `intro-buildsystem_files.json`  | Full list of all meson build files                                  |
-| `intro-dependencies.json`       | Lists all dependencies used in the project                          |
-| `intro-installed.json`          | Contains mapping of files to their installed location               |
-| `intro-projectinfo.json`        | Stores basic information about the project (name, version, etc.)    |
-| `intro-targets.json`            | Full list of all build targets                                      |
-| `intro-tests.json`              | Lists all tests with instructions how to run them                   |
+| File                           | Description                                                         |
+| ------------------------------ | ------------------------------------------------------------------- |
+| `intro-benchmarks.json`        | Lists all benchmarks                                                |
+| `intro-buildoptions.json`      | Contains a full list of meson configuration options for the project |
+| `intro-buildsystem_files.json` | Full list of all meson build files                                  |
+| `intro-dependencies.json`      | Lists all dependencies used in the project                          |
+| `intro-installed.json`         | Contains mapping of files to their installed location               |
+| `intro-projectinfo.json`       | Stores basic information about the project (name, version, etc.)    |
+| `intro-targets.json`           | Full list of all build targets                                      |
+| `intro-tests.json`             | Lists all tests with instructions how to run them                   |
 
 The content of the JSON files is further specified in the remainder of this document.
 
@@ -99,15 +100,15 @@ for actual compilation.
 
 The following table shows all valid types for a target.
 
-| value of `type`  | Description                                  |
-| ---------------  | -----------                                  |
-| `executable`     | This target will generate an executable file |
-| `static library` | Target for a static library                  |
-| `shared library` | Target for a shared library                  |
+| value of `type`  | Description                                                                                   |
+| ---------------- | --------------------------------------------------------------------------------------------- |
+| `executable`     | This target will generate an executable file                                                  |
+| `static library` | Target for a static library                                                                   |
+| `shared library` | Target for a shared library                                                                   |
 | `shared module`  | A shared library that is meant to be used with dlopen rather than linking into something else |
-| `custom`         | A custom target                              |
-| `run`            | A Meson run target                           |
-| `jar`            | A Java JAR target                            |
+| `custom`         | A custom target                                                                               |
+| `run`            | A Meson run target                                                                            |
+| `jar`            | A Java JAR target                                                                             |
 
 ### Using `--targets` without a build directory
 
@@ -227,8 +228,8 @@ in the `meson.build`.
 
 ## Tests
 
-Compilation and unit tests are done as usual by running the `ninja` and
-`ninja test` commands. A JSON formatted result log can be found in
+Compilation and unit tests are done as usual by running the `meson compile` and
+`meson test` commands. A JSON formatted result log can be found in
 `workspace/project/builddir/meson-logs/testlog.json`.
 
 When these tests fail, the user probably wants to run the failing test in a
@@ -275,11 +276,62 @@ command line. Use `meson introspect -h` to see all available options.
 
 This API can also work without a build directory for the `--projectinfo` command.
 
+# AST of a `meson.build`
+
+Since meson *0.55.0* it is possible to dump the AST of a `meson.build` as a JSON
+object. The interface for this is `meson introspect --ast /path/to/meson.build`.
+
+Each node of the AST has at least the following entries:
+
+| Key          | Description                                             |
+| ------------ | ------------------------------------------------------- |
+| `node`       | Type of the node (see following table)                  |
+| `lineno`     | Line number of the node in the file                     |
+| `colno`      | Column number of the node in the file                   |
+| `end_lineno` | Marks the end of the node (may be the same as `lineno`) |
+| `end_colno`  | Marks the end of the node (may be the same as `colno`)  |
+
+Possible values for `node` with additional keys:
+
+| Node type            | Additional keys                                  |
+| -------------------- | ------------------------------------------------ |
+| `BooleanNode`        | `value`: bool                                    |
+| `IdNode`             | `value`: str                                     |
+| `NumberNode`         | `value`: int                                     |
+| `StringNode`         | `value`: str                                     |
+| `ContinueNode`       |                                                  |
+| `BreakNode`          |                                                  |
+| `ArgumentNode`       | `positional`: node list; `kwargs`: accept_kwargs |
+| `ArrayNode`          | `args`: node                                     |
+| `DictNode`           | `args`: node                                     |
+| `EmptyNode`          |                                                  |
+| `OrNode`             | `left`: node; `right`: node                      |
+| `AndNode`            | `left`: node; `right`: node                      |
+| `ComparisonNode`     | `left`: node; `right`: node; `ctype`: str        |
+| `ArithmeticNode`     | `left`: node; `right`: node; `op`: str           |
+| `NotNode`            | `right`: node                                    |
+| `CodeBlockNode`      | `lines`: node list                               |
+| `IndexNode`          | `object`: node; `index`: node                    |
+| `MethodNode`         | `object`: node; `args`: node; `name`: str        |
+| `FunctionNode`       | `args`: node; `name`: str                        |
+| `AssignmentNode`     | `value`: node; `var_name`: str                   |
+| `PlusAssignmentNode` | `value`: node; `var_name`: str                   |
+| `ForeachClauseNode`  | `items`: node; `block`: node; `varnames`: list   |
+| `IfClauseNode`       | `ifs`: node list; `else`: node                   |
+| `IfNode`             | `condition`: node; `block`: node                 |
+| `UMinusNode`         | `right`: node                                    |
+| `TernaryNode`        | `condition`: node; `true`: node; `false`: node   |
+
+We do not guarantee the stability of this format since it is heavily linked to
+the internal Meson AST. However, breaking changes (removal of a node type or the
+removal of a key) are unlikely and will be announced in the release notes.
+
+
 # Existing integrations
 
 - [Gnome Builder](https://wiki.gnome.org/Apps/Builder)
 - [KDevelop](https://www.kdevelop.org)
 - [Eclipse CDT](https://www.eclipse.org/cdt/) (experimental)
-- [Meson Cmake Wrapper](https://github.com/prozum/meson-cmake-wrapper) (for cmake IDEs)
+- [Meson Cmake Wrapper](https://github.com/prozum/meson-cmake-wrapper) (for cmake IDEs) (currently unmaintained !!)
 - [Meson-UI](https://github.com/michaelbadcrumble/meson-ui) (Meson build GUI)
 - [Meson Syntax Highlighter](https://plugins.jetbrains.com/plugin/13269-meson-syntax-highlighter) plugin for JetBrains IDEs.
diff --git a/docs/markdown/IndepthTutorial.md b/docs/markdown/IndepthTutorial.md
index dd93f82..d2e2662 100644
--- a/docs/markdown/IndepthTutorial.md
+++ b/docs/markdown/IndepthTutorial.md
@@ -79,12 +79,12 @@ With these four files we are done. To configure, build and run the test suite, w
 
 ```console
 $ meson builddir && cd builddir
-$ ninja
-$ ninja test
+$ meson compile
+$ meson test
 ```
 
 To then install the project you only need one command.
 
 ```console
-$ ninja install
+$ meson install
 ```
diff --git a/docs/markdown/Installing.md b/docs/markdown/Installing.md
index 5abfdd4..9dc2ad4 100644
--- a/docs/markdown/Installing.md
+++ b/docs/markdown/Installing.md
@@ -4,6 +4,18 @@ short-description: Installing targets
 
 # Installing
 
+Invoked via the [following command](Commands.md#install) *(available since 0.47.0)*:
+
+```sh
+meson install
+```
+
+or alternatively (on older meson versions with `ninja` backend):
+
+```sh
+ninja install
+```
+
 By default Meson will not install anything. Build targets can be
 installed by tagging them as installable in the definition.
 
@@ -97,15 +109,13 @@ packages. This is done with the `DESTDIR` environment variable and it
 is used just like with other build systems:
 
 ```console
-$ DESTDIR=/path/to/staging/area ninja install
+$ DESTDIR=/path/to/staging/area meson install
 ```
 
 ## Custom install behaviour
 
-The default install target (executed via, e.g., `ninja install`) does
-installing with reasonable default options. More control over the
-install behaviour can be achieved with the `meson install` command,
-that has been available since 0.47.0.
+Installation behaviour can be further customized using 
+additional arguments.
 
 For example, if you wish to install the current setup without
 rebuilding the code (which the default install target always does) and
diff --git a/docs/markdown/Kconfig-module.md b/docs/markdown/Keyval-module.md
index 5807f8d..afc48fa 100644
--- a/docs/markdown/Kconfig-module.md
+++ b/docs/markdown/Keyval-module.md
@@ -1,15 +1,15 @@
 ---
-short-description: Unstable kconfig module
+short-description: Keyval module
 authors:
     - name: Mark Schulte, Paolo Bonzini
       years: [2017, 2019]
       has-copyright: false
 ...
 
-# Unstable kconfig module
+# keyval module
 
-This module parses Kconfig output files to allow use of kconfig
-configurations in meson projects.
+This module parses files consisting of a series of `key=value` lines.  One use
+of this module is to load kconfig configurations in meson projects.
 
 **Note**: this does not provide kconfig frontend tooling to generate a
 configuration. You still need something such as kconfig frontends (see
@@ -23,20 +23,23 @@ chosen the configuration options), output a ".config" file.
 The module may be imported as follows:
 
 ``` meson
-kconfig = import('unstable-kconfig')
+keyval = import('keyval')
 ```
 
 The following functions will then be available as methods on the object
-with the name `kconfig`. You can, of course, replace the name
-`kconfig` with anything else.
+with the name `keyval`. You can, of course, replace the name
+`keyval` with anything else.
 
-### kconfig.load()
+### keyval.load()
 
-This function loads a kconfig output file and returns a dictionary object.
+This function loads a file consisting of a series of `key=value` lines
+and returns a dictionary object.
 
-`kconfig.load()` makes no attempt at parsing the values in the
-file.  Therefore, true boolean values will be represented as the string "y"
-and integer values will have to be converted with `.to_int()`.
+`keyval.load()` makes no attempt at parsing the values in the file.
+In particular boolean and integer values will be represented as strings,
+and strings will keep any quoting that is present in the input file.  It
+can be useful to create a [`configuration_data()`](#configuration_data)
+object from the dictionary and use methods such as `get_unquoted()`.
 
 Kconfig frontends usually have ".config" as the default name for the
 configuration file.  However, placing the configuration file in the source
diff --git a/docs/markdown/Localisation.md b/docs/markdown/Localisation.md
index ce9e3b6..ed63e13 100644
--- a/docs/markdown/Localisation.md
+++ b/docs/markdown/Localisation.md
@@ -48,7 +48,7 @@ Then we need to generate the main pot file. The potfile can have any name but is
 Run the following command from your build folder to generate the pot file. It is recommended to inspect it manually afterwards and fill in e.g. proper copyright and contact information.
 
 ```console
-$ ninja intltest-pot
+$ meson compile intltest-pot
 ```
 
 ### generate .po files
@@ -56,5 +56,5 @@ $ ninja intltest-pot
 For each language listed in the array above we need a corresponding `.po` file. Those can be generated by running the following command from your build folder.
 
 ```console
-$ ninja intltest-update-po
+$ meson compile intltest-update-po
 ```
diff --git a/docs/markdown/Machine-files.md b/docs/markdown/Machine-files.md
index 404c3d2..5ac66a8 100644
--- a/docs/markdown/Machine-files.md
+++ b/docs/markdown/Machine-files.md
@@ -5,24 +5,132 @@ documentation on the common values used by both, for the specific values of
 one or the other see the [cross compilation](Cross-compilation.md) and [native
 environments](Native-environments.md).
 
+## Data Types
+
+There are four basic data types in a machine file:
+- strings
+- arrays
+- booleans
+- integers
+
+A string is specified single quoted:
+```ini
+[section]
+option1 = 'false'
+option2 = '2'
+```
+
+An array is enclosed in square brackets, and must consist of strings or booleans
+```ini
+[section]
+option = ['value']
+```
+
+A boolean must be either `true` or `false`, and unquoted.
+```ini
+option = false
+```
+
+An integer must be either an unquoted numeric constant;
+```ini
+option = 42
+```
+
 ## Sections
 
 The following sections are allowed:
+- constants
 - binaries
 - paths
 - properties
+- project options
+- built-in options
+
+### constants
+
+*Since 0.56.0*
+
+String and list concatenation is supported using the `+` operator, joining paths
+is supported using the `/` operator.
+Entries defined in the `[constants]` section can be used in any other section
+(they are always parsed first), entries in any other section can be used only
+within that same section and only after it has been defined.
+
+```ini
+[constants]
+toolchain = '/toolchain'
+common_flags = ['--sysroot=' + toolchain / 'sysroot']
+
+[properties]
+c_args = common_flags + ['-DSOMETHING']
+cpp_args = c_args + ['-DSOMETHING_ELSE']
+
+[binaries]
+c = toolchain / 'gcc'
+```
+
+This can be useful with cross file composition as well. A generic cross file
+could be composed with a platform specific file where constants are defined:
+```ini
+# aarch64.ini
+[constants]
+arch = 'aarch64-linux-gnu'
+```
+
+```ini
+# cross.ini
+[binaries]
+c = arch + '-gcc'
+cpp = arch + '-g++'
+strip = arch + '-strip'
+pkgconfig = arch + '-pkg-config'
+...
+```
+
+This can be used as `meson setup --cross-file aarch64.ini --cross-file cross.ini builddir`.
+
+Note that file composition happens before the parsing of values. The example
+below results in `b` being `'HelloWorld'`:
+```ini
+# file1.ini:
+[constants]
+a = 'Foo'
+b = a + 'World'
+```
+
+```ini
+#file2.ini:
+[constants]
+a = 'Hello'
+```
+
+The example below results in an error when file1.ini is included before file2.ini
+because `b` would be defined before `a`:
+```ini
+# file1.ini:
+[constants]
+b = a + 'World'
+```
+
+```ini
+#file2.ini:
+[constants]
+a = 'Hello'
+```
 
 ### Binaries
 
 The binaries section contains a list of binaries. These can be used
-internally by meson, or by the `find_program` function:
+internally by meson, or by the `find_program` function.
+
+These values must be either strings or an array of strings
 
 Compilers and linkers are defined here using `<lang>` and `<lang>_ld`.
 `<lang>_ld` is special because it is compiler specific. For compilers like
 gcc and clang which are used to invoke the linker this is a value to pass to
 their "choose the linker" argument (-fuse-ld= in this case). For compilers
 like MSVC and Clang-Cl, this is the path to a linker for meson to invoke,
-such as `link.exe` or `lld-link.exe`. Support for ls is *new in 0.53.0*
+such as `link.exe` or `lld-link.exe`. Support for `ld` is *new in 0.53.0*
 
 *changed in 0.53.1* the `ld` variable was replaced by `<lang>_ld`, because it
 *regressed a large number of projects. in 0.53.0 the `ld` variable was used
@@ -40,8 +148,8 @@ llvm-config = '/usr/lib/llvm8/bin/llvm-config'
 Cross example:
 
 ```ini
-c = '/usr/bin/i586-mingw32msvc-gcc'
-cpp = '/usr/bin/i586-mingw32msvc-g++'
+c = ['ccache', '/usr/bin/i586-mingw32msvc-gcc']
+cpp = ['ccache', '/usr/bin/i586-mingw32msvc-g++']
 c_ld = 'gold'
 cpp_ld = 'gold'
 ar = '/usr/i586-mingw32msvc/bin/ar'
@@ -64,8 +172,10 @@ An incomplete list of internally used programs that can be overridden here is:
 
 ### Paths and Directories
 
+*Deprecated in 0.56.0* use the built-in section instead.
+
 As of 0.50.0 paths and directories such as libdir can be defined in the native
-file in a paths section
+and cross files in a paths section. These should be strings.
 
 ```ini
 [paths]
@@ -84,21 +194,79 @@ command line will override any options in the native file. For example, passing
 
 In addition to special data that may be specified in cross files, this
 section may contain random key value pairs accessed using the
-`meson.get_external_property()`
+`meson.get_external_property()`, or `meson.get_cross_property()`.
+
+*Changed in 0.56.0* putting `<lang>_args` and `<lang>_link_args` in the
+properties section has been deprecated, and should be put in the built-in
+options section.
+
+### Project specific options
+
+*New in 0.56.0*
+
+Path options are not allowed, those must be set in the `[paths]` section.
+
+Being able to set project specific options in a cross or native file can be
+done using the `[project options]` section of the specific file (if doing a
+cross build the options from the native file will be ignored)
+
+For setting options in subprojects use the `[<subproject>:project options]`
+section instead.
+
+```ini
+[project options]
+build-tests = true
+
+[zlib:project options]
+build-tests = false
+```
+
+### Meson built-in options
+
+Meson built-in options can be set the same way:
+
+```ini
+[built-in options]
+c_std = 'c99'
+```
+
+You can set some meson built-in options on a per-subproject basis, such as
+`default_library` and `werror`. The order of precedence is:
+1) Command line
+2) Machine file
+3) Build system definitions
+
+```ini
+[zlib:built-in options]
+default_library = 'static'
+werror = false
+```
+
+Options set on a per-subproject basis will inherit the
+option from the parent if the parent has a setting but the subproject
+doesn't, even when there is a default set meson language.
+
+```ini
+[built-in options]
+default_library = 'static'
+```
 
-## Properties
+will make subprojects use default_library as static.
 
-*New for native files in 0.54.0*
+Some options can be set on a per-machine basis (in other words, the value of
+the build machine can be different than the host machine in a cross compile).
+In these cases the values from both a cross file and a native file are used.
 
-The properties section can contain any variable you like, and is accessed via
-`meson.get_external_property`, or `meson.get_cross_property`.
+An incomplete list of options is:
+- pkg_config_path
+- cmake_prefix_path
 
 ## Loading multiple machine files
 
 Native files allow layering (cross files can be layered since meson 0.52.0).
-More than one native file can be loaded, with values from a previous file being
+More than one file can be loaded, with values from a previous file being
 overridden by the next. The intention of this is not overriding, but to allow
-composing native files. This composition is done by passing the command line
+composing files. This composition is done by passing the command line
 argument multiple times:
 
 ```console
diff --git a/docs/markdown/Meson-sample.md b/docs/markdown/Meson-sample.md
index 6f26f36..f98e022 100644
--- a/docs/markdown/Meson-sample.md
+++ b/docs/markdown/Meson-sample.md
@@ -50,7 +50,7 @@ exe = executable('myexe', src)
 test('simple test', exe)
 ```
 
-Here we create a unit test called *simple test*, and which uses the built executable. When the tests are run with the `ninja test` command, the built executable is run. If it returns zero, the test passes. A non-zero return value indicates an error, which Meson will then report to the user.
+Here we create a unit test called *simple test*, and which uses the built executable. When the tests are run with the `meson test` command, the built executable is run. If it returns zero, the test passes. A non-zero return value indicates an error, which Meson will then report to the user.
 
 A note to Visual Studio users
 -----
diff --git a/docs/markdown/MesonCI.md b/docs/markdown/MesonCI.md
new file mode 100644
index 0000000..73b979b
--- /dev/null
+++ b/docs/markdown/MesonCI.md
@@ -0,0 +1,53 @@
+# Meson CI setup
+
+This document is aimed for Meson contributors and documents
+the CI setup used for testing Meson itself. The Meson
+project uses multiple CI platforms for covering a wide
+range of target systems.
+
+## Travis CI
+
+The travis configuration file is the `.travis.yml` in the
+the project root. This platform tests cross compilation and
+unity builds on a [linux docker image](#docker-images) and
+on OSX.
+
+## GitHub actions
+
+The configuration files for GitHub actions are located in
+`.github/workflows`. Here, all [images](#docker-images)
+are tested  with the full `run_tests.py` run. Additionally,
+some other, smaller, tests are run.
+
+## Docker images
+
+The Linux docker images are automatically built and
+uploaded by GitHub actions. An image rebuild is triggerd
+when any of the image definition files are changed (in
+`ci/ciimage`) in the master branch. Additionally, the
+images are also updated weekly.
+
+Each docker image has one corresponding dirctory in
+`ci/ciimage` with an `image.json` and an `install.sh`.
+
+### Image generation
+
+There are no manual Dockerfiles. Instead the Dockerfile is
+automatically generated by the `build.py` script. This is
+done to ensure that all images have the same layout and can
+all be built and tested automatically.
+
+The Dockerfile is generated from the `image.json` file and
+basically only adds a few common files and runs the
+`install.sh` script which should contain all distribution
+specific setup steps. The `common.sh` can be sourced via
+`source /ci/common.sh` to access some shared functionalety.
+
+To generate the image run `build.py -t build <image>`. A
+generated image can be tested with `build.py -t test <image>`.
+
+### Common image setup
+
+Each docker image has a `/ci` directory with an
+`env_vars.sh` script. This script has to be sourced before
+running the meson test suite.
diff --git a/docs/markdown/Precompiled-headers.md b/docs/markdown/Precompiled-headers.md
index d9ac7a4..05b50bc 100644
--- a/docs/markdown/Precompiled-headers.md
+++ b/docs/markdown/Precompiled-headers.md
@@ -51,7 +51,7 @@ Using precompiled headers with GCC and derivatives
 --
 
 Once you have a file to precompile, you can enable the use of pch for
-a give target with a *pch* keyword argument. As an example, let's assume
+a given target with a *pch* keyword argument. As an example, let's assume
 you want to build a small C binary with precompiled headers.
 Let's say the source files of the binary use the system headers `stdio.h`
 and `string.h`. Then you create a header file `pch/myexe_pch.h` with this
diff --git a/docs/markdown/Project-templates.md b/docs/markdown/Project-templates.md
index 5f323bd..7ded318 100644
--- a/docs/markdown/Project-templates.md
+++ b/docs/markdown/Project-templates.md
@@ -16,15 +16,34 @@ $ meson init --language=c --name=myproject --version=0.1
 ```
 
 This would create the build definitions for a helloworld type
-project. The result can be compiled as usual. For example compiling it
-with Ninja could be done like this:
+project. The result can be compiled as usual. For example it
+could be done like this:
 
 ```
-$ meson builddir
-$ ninja -C builddir
+$ meson setup builddir
+$ meson compile -C builddir
 ```
 
 The generator has many different projects and settings. They can all
 be listed by invoking the command `meson init --help`.
 
 This feature is available since Meson version 0.45.0.
+
+# Generate a build script for an existing project
+
+With `meson init` you can generate a build script for an existing
+project with existing project files by running the command in the
+root directory of your project. Meson currently supports this
+feature for `executable`, and `jar` projects.
+
+# Build after generation of template
+
+It is possible to have Meson generate a build directory from the
+`meson init` command without running `meson setup`. This is done
+by passing `-b` or `--build` switch.
+
+```console
+$ mkdir project_name
+$ cd project_name
+$ meson init --language=c --name=myproject --version=0.1 --build
+```
\ No newline at end of file
diff --git a/docs/markdown/Qt5-module.md b/docs/markdown/Qt5-module.md
index f1c2f6c..0d9a6b6 100644
--- a/docs/markdown/Qt5-module.md
+++ b/docs/markdown/Qt5-module.md
@@ -21,7 +21,7 @@ This method generates the necessary targets to build translation files with lrel
  - `ts_files`, the list of input translation files produced by Qt's lupdate tool.
  - `install` when true, this target is installed during the install step (optional).
  - `install_dir` directory to install to (optional).
- - `build_by_default` when set to true, to have this target be built by default, that is, when invoking plain ninja; the default value is false (optional).
+ - `build_by_default` when set to true, to have this target be built by default, that is, when invoking `meson compile`; the default value is false (optional).
 
 ## has_tools
 
diff --git a/docs/markdown/Quick-guide.md b/docs/markdown/Quick-guide.md
index 0bed683..74636e5 100644
--- a/docs/markdown/Quick-guide.md
+++ b/docs/markdown/Quick-guide.md
@@ -93,8 +93,8 @@ are working on. The steps to take are very simple.
 ```console
 $ cd /path/to/source/root
 $ meson builddir && cd builddir
-$ ninja
-$ ninja test
+$ meson compile
+$ meson test
 ```
 
 The only thing to note is that you need to create a separate build
@@ -104,14 +104,14 @@ directory. This allows you to have multiple build trees with different
 configurations at the same time. This way generated files are not
 added into revision control by accident.
 
-To recompile after code changes, just type `ninja`. The build command
+To recompile after code changes, just type `meson compile`. The build command
 is always the same. You can do arbitrary changes to source code and
 build system files and Meson will detect those and will do the right
 thing. If you want to build optimized binaries, just use the argument
 `--buildtype=debugoptimized` when running Meson. It is recommended
 that you keep one build directory for unoptimized builds and one for
 optimized ones. To compile any given configuration, just go into the
-corresponding build directory and run `ninja`.
+corresponding build directory and run `meson compile`.
 
 Meson will automatically add compiler flags to enable debug
 information and compiler warnings (i.e. `-g` and `-Wall`). This means
@@ -128,9 +128,9 @@ build and install Meson projects are the following.
 ```console
 $ cd /path/to/source/root
 $ meson --prefix /usr --buildtype=plain builddir -Dc_args=... -Dcpp_args=... -Dc_link_args=... -Dcpp_link_args=...
-$ ninja -v -C builddir
-$ ninja -C builddir test
-$ DESTDIR=/path/to/staging/root ninja -C builddir install
+$ meson compile -C builddir
+$ meson test -C builddir
+$ DESTDIR=/path/to/staging/root meson install -C builddir
 ```
 
 The command line switch `--buildtype=plain` tells Meson not to add its
@@ -139,7 +139,7 @@ on used flags.
 
 This is very similar to other build systems. The only difference is
 that the `DESTDIR` variable is passed as an environment variable
-rather than as an argument to `ninja install`.
+rather than as an argument to `meson install`.
 
 As distro builds happen always from scratch, you might consider
 enabling [unity builds](Unity-builds.md) on your packages because they
diff --git a/docs/markdown/Reference-manual.md b/docs/markdown/Reference-manual.md
index 5156b5b..080fe3e 100644
--- a/docs/markdown/Reference-manual.md
+++ b/docs/markdown/Reference-manual.md
@@ -15,19 +15,19 @@ afterwards](#returned-objects).
 Adds the positional arguments to the compiler command line. This
 function has two keyword arguments:
 
-- `language` specifies the language(s) that the arguments should be
+- `language`: specifies the language(s) that the arguments should be
 applied to. If a list of languages is given, the arguments are added
 to each of the corresponding compiler command lines. Note that there
 is no way to remove an argument set in this way. If you have an
 argument that is only used in a subset of targets, you have to specify
 it in per-target flags.
 
-- `native` is a boolean specifying whether the arguments should be
+- `native` *(since 0.48.0)*: a boolean specifying whether the arguments should be
   applied to the native or cross compilation. If `true` the arguments
   will only be used for native compilations. If `false` the arguments
   will only be used in cross compilations. If omitted, the flags are
   added to native compilations if compiling natively and cross
-  compilations (only) when cross compiling. Available since 0.48.0
+  compilations (only) when cross compiling.
 
 The arguments are used in all compiler invocations with the exception
 of compile tests, because you might need to run a compile test with
@@ -70,12 +70,12 @@ endif
 
 Takes the following keyword arguments:
 
-- `required` defaults to `true`, which means that if any of the languages
-specified is not found, Meson will halt. Since *0.47.0* the value of a
+- `required`: defaults to `true`, which means that if any of the languages
+specified is not found, Meson will halt. *(since 0.47.0)* The value of a
 [`feature`](Build-options.md#features) option can also be passed.
 
-- `native` if set to `true`, the language will be used to compile for the build
-  machine, if `false`, for the host machine. Since *0.54.0*.
+- `native` *(since 0.54.0)*: if set to `true`, the language will be used to compile for the build
+  machine, if `false`, for the host machine.
 
 Returns `true` if all languages specified were found and `false` otherwise.
 
@@ -113,16 +113,16 @@ Add a custom test setup that can be used to run the tests with a
 custom setup, for example under Valgrind. The keyword arguments are
 the following:
 
-- `env` environment variables to set, such as `['NAME1=value1',
+- `env`: environment variables to set, such as `['NAME1=value1',
   'NAME2=value2']`, or an [`environment()`
   object](#environment-object) which allows more sophisticated
-  environment juggling. *Since 0.52.0* a dictionary is also accepted.
-- `exe_wrapper` a list containing the wrapper command or script followed by the arguments to it
-- `gdb` if `true`, the tests are also run under `gdb`
-- `timeout_multiplier` a number to multiply the test timeout with
-- `is_default` a bool to set whether this is the default test setup.
+  environment juggling. *(since 0.52.0)* A dictionary is also accepted.
+- `exe_wrapper`: a list containing the wrapper command or script followed by the arguments to it
+- `gdb`: if `true`, the tests are also run under `gdb`
+- `timeout_multiplier`: a number to multiply the test timeout with
+- `is_default` *(since 0.49.0)*: a bool to set whether this is the default test setup.
   If `true`, the setup will be used whenever `meson test` is run
-  without the `--setup` option. Since 0.49.0
+  without the `--setup` option.
 
 To use the test setup, run `meson test --setup=*name*` inside the
 build dir.
@@ -137,11 +137,11 @@ Note that all these options are also available while running the
 runtarget alias_target(target_name, dep1, ...)
 ```
 
-Since *0.52.0*
+*(since 0.52.0)*
 
 This function creates a new top-level target. Like all top-level targets, this
-integrates with the selected backend. For instance, with Ninja you can
-run it as `ninja target_name`. This is a dummy target that does not execute any
+integrates with the selected backend. For instance, with you can
+run it as `meson compile target_name`. This is a dummy target that does not execute any
 command, but ensures that all dependencies are built. Dependencies can be any
 build target (e.g. return value of [executable()](#executable), custom_target(), etc)
 
@@ -153,7 +153,7 @@ build target (e.g. return value of [executable()](#executable), custom_target(),
 
 Abort with an error message if `condition` evaluates to `false`.
 
-*Since 0.53.0* `message` argument is optional and defaults to print the condition
+*(since 0.53.0)* `message` argument is optional and defaults to print the condition
 statement instead.
 
 ### benchmark()
@@ -169,7 +169,7 @@ run. The behavior of this function is identical to [`test()`](#test) except for:
 * benchmark() does not automatically add the `MALLOC_PERTURB_` environment variable
 
 *Note:* Prior to 0.52.0 benchmark would warn that `depends` and `priority`
-were unsupported, this is incorrect
+were unsupported, this is incorrect.
 
 ### both_libraries()
 
@@ -177,6 +177,8 @@ were unsupported, this is incorrect
     buildtarget = both_libraries(library_name, list_of_sources, ...)
 ```
 
+*(since 0.46.0)*
+
 Builds both a static and shared library with the given
 sources. Positional and keyword arguments are otherwise the same as
 for [`library`](#library). Source files will be compiled only once and
@@ -190,8 +192,6 @@ shared library. In addition it supports the following extra methods:
 - `get_shared_lib()` returns the shared library build target
 - `get_static_lib()` returns the static library build target
 
-*Added 0.46.0*
-
 ### build_target()
 
 Creates a build target whose type can be set dynamically with the
@@ -234,7 +234,7 @@ Creates an empty configuration object. You should add your
 configuration with [its method calls](#configuration-data-object) and
 finally use it in a call to `configure_file`.
 
-Since *0.49.0* takes an optional dictionary as first argument. If
+*(since 0.49.0)* Takes an optional dictionary as first argument. If
 provided, each key/value pair is added into the `configuration_data`
 as if `set()` method was called for each of them.
 
@@ -251,7 +251,7 @@ When a [`configuration_data()`](#configuration_data) object is passed
 to the `configuration:` keyword argument, it takes a template file as
 the `input:` (optional) and produces the `output:` (required) by
 substituting values from the configuration data as detailed in [the
-configuration file documentation](Configuration.md). Since *0.49.0* a
+configuration file documentation](Configuration.md). *(since 0.49.0)* A
 dictionary can be passed instead of a
 [`configuration_data()`](#configuration_data) object.
 
@@ -259,53 +259,53 @@ When a list of strings is passed to the `command:` keyword argument,
 it takes any source or configured file as the `input:` and assumes
 that the `output:` is produced when the specified command is run.
 
-Since *0.47.0*, when the `copy:` keyword argument is set to `true`,
+*(since 0.47.0)* When the `copy:` keyword argument is set to `true`,
 this function will copy the file provided in `input:` to a file in the
 build directory with the name `output:` in the current directory.
 
 These are all the supported keyword arguments:
 
-- `capture` when this argument is set to true, Meson captures `stdout`
-  of the `command` and writes it to the target file specified as
-  `output`. Available since v0.41.0.
-- `command` as explained above, if specified, Meson does not create
+- `capture` *(since 0.41.0)*: when this argument is set to true,
+  Meson captures `stdout` of the `command` and writes it to the target 
+  file specified as `output`.
+- `command`: as explained above, if specified, Meson does not create
   the file itself but rather runs the specified command, which allows
-  you to do fully custom file generation. Since *0.52.0* the command can contain
+  you to do fully custom file generation. *(since 0.52.0)* The command can contain
   file objects and more than one file can be passed to the `input` keyword
   argument, see [`custom_target()`](#custom_target) for details about string
   substitutions.
-- `copy` *(added 0.47.0)* as explained above, if specified Meson only
+- `copy` *(since 0.47.0)*: as explained above, if specified Meson only
   copies the file from input to output.
-- `depfile` *(added 0.52.0)* is a dependency file that the command can write listing
+- `depfile` *(since 0.52.0)*: a dependency file that the command can write listing
   all the additional files this target depends on. A change
   in any one of these files triggers a reconfiguration.
-- `format` *(added 0.46.0)* the format of defines. It defaults to `meson`, and so substitutes
+- `format` *(since 0.46.0)*: the format of defines. It defaults to `meson`, and so substitutes
 `#mesondefine` statements and variables surrounded by `@` characters, you can also use `cmake`
 to replace `#cmakedefine` statements and variables with the `${variable}` syntax. Finally you can use
 `cmake@` in which case substitutions will apply on `#cmakedefine` statements and variables with
 the `@variable@` syntax.
-- `input` the input file name. If it's not specified in configuration
+- `input`: the input file name. If it's not specified in configuration
   mode, all the variables in the `configuration:` object (see above)
   are written to the `output:` file.
-- `install` *(added 0.50.0)* When true, this generated file is installed during
+- `install` *(since 0.50.0)*: when true, this generated file is installed during
 the install step, and `install_dir` must be set and not empty. When false, this
 generated file is not installed regardless of the value of `install_dir`.
 When omitted it defaults to true when `install_dir` is set and not empty,
 false otherwise.
-- `install_dir` the subdirectory to install the generated file to
+- `install_dir`: the subdirectory to install the generated file to
   (e.g. `share/myproject`), if omitted or given the value of empty
   string, the file is not installed.
-- `install_mode` *(added 0.47.0)* specify the file mode in symbolic format
+- `install_mode` *(since 0.47.0)*: specify the file mode in symbolic format
   and optionally the owner/uid and group/gid for the installed files.
-- `output` the output file name (since v0.41.0, may contain
-  `@PLAINNAME@` or `@BASENAME@` substitutions). In configuration mode,
+- `output`: the output file name. *(since 0.41.0)* may contain
+  `@PLAINNAME@` or `@BASENAME@` substitutions. In configuration mode,
   the permissions of the input file (if it is specified) are copied to
   the output file.
-- `output_format` *(added 0.47.0)* the format of the output to generate when no input
+- `output_format` *(since 0.47.0)*: the format of the output to generate when no input
   was specified. It defaults to `c`, in which case preprocessor directives
   will be prefixed with `#`, you can also use `nasm`, in which case the
   prefix will be `%`.
-- `encoding` *(added v0.47.0)* set the file encoding for the input and output file,
+- `encoding` *(since 0.47.0)*: set the file encoding for the input and output file,
   defaults to utf-8. The supported encodings are those of python3, see
   [standard-encodings](https://docs.python.org/3/library/codecs.html#standard-encodings).
 
@@ -319,34 +319,30 @@ Create a custom top level build target. The only positional argument
 is the name of this target and the keyword arguments are the
 following.
 
-- `build_by_default` *(added 0.38)* causes, when set to true, to
+- `build_by_default` *(since 0.38.0)*: causes, when set to true, to
   have this target be built by default. This means it will be built when
-  `ninja` is called without any arguments or asked to build a target
-  like `ninja test` that depends on ninja's [default
-  target](https://ninja-build.org/manual.html#_default_target_statements)
-  set to `all` by meson. The same behavior applies for backends other
-  than `ninja`.  The default value is `false`.
-  *(changed in 0.50)* if `build_by_default` is explicitly set to false, `install`
+  `meson compile` is called without any arguments. The default value is `false`.
+  *(since 0.50.0)* If `build_by_default` is explicitly set to false, `install`
   will no longer override it. If `build_by_default` is not set, `install` will
   still determine its default.
-- `build_always` (deprecated) if `true` this target is always considered out of
+- `build_always` **(deprecated)**: if `true` this target is always considered out of
   date and is rebuilt every time.  Equivalent to setting both
   `build_always_stale` and `build_by_default` to true.
-- `build_always_stale` *(added 0.47)* if `true` the target is always considered out of date.
+- `build_always_stale` *(since 0.47.0)*: if `true` the target is always considered out of date.
   Useful for things such as build timestamps or revision control tags.
   The associated command is run even if the outputs are up to date.
-- `capture`, there are some compilers that can't be told to write
+- `capture`: there are some compilers that can't be told to write
   their output to a file but instead write it to standard output. When
   this argument is set to true, Meson captures `stdout` and writes it
   to the target file. Note that your command argument list may not
   contain `@OUTPUT@` when capture mode is active.
-- `console` *(added 0.48)* keyword argument conflicts with `capture`, and is meant
+- `console` *(since 0.48.0)*: keyword argument conflicts with `capture`, and is meant
   for commands that are resource-intensive and take a long time to
   finish. With the Ninja backend, setting this will add this target
   to [Ninja's `console` pool](https://ninja-build.org/manual.html#_the_literal_console_literal_pool),
   which has special properties such as not buffering stdout and
   serializing all targets in this pool.
-- `command` command to run to create outputs from inputs. The command
+- `command`: command to run to create outputs from inputs. The command
   may be strings or the return value of functions that return file-like
   objects such as [`find_program()`](#find_program),
   [`executable()`](#executable), [`configure_file()`](#configure_file),
@@ -356,48 +352,47 @@ following.
   Note: always specify commands in array form `['commandname',
   '-arg1', '-arg2']` rather than as a string `'commandname -arg1
   -arg2'` as the latter will *not* work.
-- `depend_files` files ([`string`](#string-object),
+- `depend_files`: files ([`string`](#string-object),
   [`files()`](#files), or [`configure_file()`](#configure_file)) that
   this target depends on but are not listed in the `command` keyword
   argument. Useful for adding regen dependencies.
-- `depends` specifies that this target depends on the specified
+- `depends`: specifies that this target depends on the specified
   target(s), even though it does not take any of them as a command
   line argument. This is meant for cases where you have a tool that
   e.g. does globbing internally. Usually you should just put the
   generated sources as inputs and Meson will set up all dependencies
   automatically.
-- `depfile` is a dependency file that the command can write listing
+- `depfile`: a dependency file that the command can write listing
   all the additional files this target depends on, for example a C
   compiler would list all the header files it included, and a change
   in any one of these files triggers a recompilation
-- `input` list of source files. As of 0.41.0 the list will be flattened.
-- `install` when true, this target is installed during the install step
-- `install_dir` directory to install to
-- `install_mode` *(added 0.47.0)* the file mode and optionally the
+- `input`: list of source files. *(since 0.41.0)* the list is flattened.
+- `install`: when true, this target is installed during the install step
+- `install_dir`: directory to install to
+- `install_mode` *(since 0.47.0)*: the file mode and optionally the
   owner/uid and group/gid
-- `output` list of output files
+- `output`: list of output files
 
 The list of strings passed to the `command` keyword argument accept
 the following special string substitutions:
 
-- `@INPUT@` the full path to the input passed to `input`. If more than
+- `@INPUT@`: the full path to the input passed to `input`. If more than
   one input is specified, all of them will be substituted as separate
   arguments only if the command uses `'@INPUT@'` as a
   standalone-argument. For instance, this would not work: `command :
   ['cp', './@INPUT@']`, but this would: `command : ['cp', '@INPUT@']`.
-- `@OUTPUT@` the full path to the output passed to `output`. If more
+- `@OUTPUT@`: the full path to the output passed to `output`. If more
   than one outputs are specified, the behavior is the same as
   `@INPUT@`.
-- `@INPUT0@` `@INPUT1@` `...` the full path to the input with the specified array index in `input`
-- `@OUTPUT0@` `@OUTPUT1@` `...` the full path to the output with the specified array index in `output`
-- `@OUTDIR@` the full path to the directory where the output(s) must be written
-- `@DEPFILE@` the full path to the dependency file passed to `depfile`
+- `@INPUT0@` `@INPUT1@` `...`: the full path to the input with the specified array index in `input`
+- `@OUTPUT0@` `@OUTPUT1@` `...`: the full path to the output with the specified array index in `output`
+- `@OUTDIR@`: the full path to the directory where the output(s) must be written
+- `@DEPFILE@`: the full path to the dependency file passed to `depfile`
 - `@PLAINNAME@`: the input filename, without a path
 - `@BASENAME@`: the input filename, with extension removed
-- `@PRIVATE_DIR@`: path to a directory where the custom target must store all its intermediate files, available since 0.50.1
+- `@PRIVATE_DIR@` *(since 0.50.1)*: path to a directory where the custom target must store all its intermediate files.
 
-The `depfile` keyword argument also accepts the `@BASENAME@` and `@PLAINNAME@`
-substitutions. *(since 0.47)*
+*(since 0.47.0)* The `depfile` keyword argument also accepts the `@BASENAME@` and `@PLAINNAME@` substitutions. 
 
 The returned object also has methods that are documented in the
 [object methods section](#custom-target-object) below.
@@ -414,22 +409,21 @@ internal to the current build. The main use case for this is in
 subprojects. This allows a subproject to easily specify how it should
 be used. This makes it interchangeable with the same dependency that
 is provided externally by the system. This function has the following
-keyword arguments.
-
-  - `compile_args`, compile arguments to use
-  - `dependencies`, other dependencies needed to use this dependency
-  - `include_directories`, the directories to add to header search path,
-    must be include_directories objects or, since 0.50.0, plain strings
-  - `link_args`, link arguments to use
-  - `link_with`, libraries to link against
-  - `link_whole`, libraries to link fully, same as [`executable`](#executable)
-    Since 0.46.0
-  - `sources`, sources to add to targets (or generated header files
-    that should be built before sources including them are built)
-  - `version`, the version of this dependency, such as `1.2.3`
-  - `variables`, a dictionary of arbitrary strings, this is meant to be used
-    in subprojects where special variables would be provided via cmake or
-    pkg-config. Since 0.54.0
+keyword arguments:
+
+- `compile_args`: compile arguments to use.
+- `dependencies`: other dependencies needed to use this dependency.
+- `include_directories`: the directories to add to header search path,
+  must be include_directories objects or *(since 0.50.0)* plain strings
+- `link_args`: link arguments to use.
+- `link_with`: libraries to link against.
+- `link_whole` *(since 0.46.0)*: libraries to link fully, same as [`executable`](#executable).
+- `sources`: sources to add to targets (or generated header files
+  that should be built before sources including them are built)
+- `version`: the version of this dependency, such as `1.2.3`
+- `variables` *(since 0.54.0)*: a dictionary of arbitrary strings, this is meant to be used
+  in subprojects where special variables would be provided via cmake or
+  pkg-config.
 
 ### dependency()
 
@@ -445,12 +439,12 @@ logic](Dependencies.md#dependencies-with-custom-lookup-functionality)
 are also supported. This function supports the following keyword
 arguments:
 
-- `default_options` *(added 0.37.0)* an array of default option values
+- `default_options` *(since 0.37.0)*: an array of default option values
   that override those set in the subproject's `meson_options.txt`
   (like `default_options` in [`project()`](#project), they only have
   effect when Meson is run for the first time, and command line
   arguments override any default options in build files)
-- `fallback` specifies a subproject fallback to use in case the
+- `fallback`: specifies a subproject fallback to use in case the
   dependency is not found in the system. The value is an array
   `['subproj_name', 'subproj_dep']` where the first value is the name
   of the subproject and the second is the variable name in that
@@ -459,36 +453,42 @@ arguments:
   [`dependency()`](#dependency), etc. Note that this means the
   fallback dependency may be a not-found dependency, in which
   case the value of the `required:` kwarg will be obeyed.
-  *Since 0.54.0* `'subproj_dep'` argument can be omitted in the case the
+  *(since 0.54.0)* `'subproj_dep'` argument can be omitted in the case the
   subproject used `meson.override_dependency('dependency_name', subproj_dep)`.
   In that case, the `fallback` keyword argument can be a single string instead
-  of a list of 2 strings.
-- `language` *(added 0.42.0)* defines what language-specific
+  of a list of 2 strings. *Since 0.55.0* the `fallback` keyword argument can be
+  omitted when there is a wrap file or a directory with the same `dependency_name`,
+  and subproject registered the dependency using
+  `meson.override_dependency('dependency_name', subproj_dep)`, or when the wrap
+  file has `dependency_name` in its `[provide]` section.
+  See [Wrap documentation](Wrap-dependency-system-manual.md#provide-section)
+  for more details.
+- `language` *(since 0.42.0)*: defines what language-specific
   dependency to find if it's available for multiple languages.
-- `method` defines the way the dependency is detected, the default is
+- `method`: defines the way the dependency is detected, the default is
   `auto` but can be overridden to be e.g. `qmake` for Qt development,
   and [different dependencies support different values](
   Dependencies.md#dependencies-with-custom-lookup-functionality)
   for this (though `auto` will work on all of them)
-- `native` if set to `true`, causes Meson to find the dependency on
+- `native`: if set to `true`, causes Meson to find the dependency on
   the build machine system rather than the host system (i.e. where the
   cross compiled binary will run on), usually only needed if you build
   a tool to be used during compilation.
-- `not_found_message` *(added 0.50.0)* is an optional string that will
+- `not_found_message` *(since 0.50.0)*: an optional string that will
   be printed as a `message()` if the dependency was not found.
-- `required`, when set to false, Meson will proceed with the build
-  even if the dependency is not found. Since *0.47.0* the value of a
+- `required`: when set to false, Meson will proceed with the build
+  even if the dependency is not found. *(since 0.47.0)* The value of a
   [`feature`](Build-options.md#features) option can also be passed.
-- `static` tells the dependency provider to try to get static
+- `static`: tells the dependency provider to try to get static
   libraries instead of dynamic ones (note that this is not supported
   by all dependency backends)
-- `version` specifies the required version, a string containing a
+- `version` *(since 0.37.0)*: specifies the required version, a string containing a
   comparison operator followed by the version string, examples include
-  `>1.0.0`, `<=2.3.5` or `3.1.4` for exact matching. *(Added 0.37.0)*
+  `>1.0.0`, `<=2.3.5` or `3.1.4` for exact matching. 
   You can also specify multiple restrictions by passing a list to this
   keyword argument, such as: `['>=3.14.0', '<=4.1.0']`.
   These requirements are never met if the version is unknown.
-- `include_type` *(added 0.52.0)* is an enum flag, marking how the dependency
+- `include_type` *(since 0.52.0)*: an enum flag, marking how the dependency
   flags should be converted. Supported values are `'preserve'`, `'system'` and
   `'non-system'`. System dependencies may be handled differently on some
    platforms, for instance, using `-isystem` instead of `-I`, where possible.
@@ -499,9 +499,8 @@ arguments:
 keywords may also be accepted (e.g. `modules` specifies submodules to use for
 dependencies such as Qt5 or Boost. `components` allows the user to manually
 add CMake `COMPONENTS` for the `find_package` lookup)
-- `disabler` if `true` and the dependency couldn't be found, return a
-  [disabler object](#disabler-object) instead of a not-found dependency.
-  *Since 0.49.0*
+- `disabler` *(since 0.49.0)*: if `true` and the dependency couldn't be found,
+  returns a [disabler object](#disabler-object) instead of a not-found dependency.
 
 If dependency_name is `''`, the dependency is always not found.  So
 with `required: false`, this always returns a dependency object for
@@ -518,7 +517,9 @@ The returned object also has methods that are documented in the
 
 ### disabler()
 
-Returns a [disabler object](#disabler-object). Added in 0.44.0.
+*(since 0.44.0)*
+
+Returns a [disabler object](#disabler-object).
 
 ### error()
 
@@ -534,10 +535,11 @@ Print the argument string and halts the build process.
     environment_object environment(...)
 ```
 
-Returns an empty [environment variable
-object](#environment-object). Added in 0.35.0.
+*(since 0.35.0)*
+
+Returns an empty [environment variable object](#environment-object).
 
-Since *0.52.0* takes an optional dictionary as first argument. If
+*(since 0.52.0)* Takes an optional dictionary as first argument. If
 provided, each key/value pair is added into the `environment_object`
 as if `set()` method was called for each of them.
 
@@ -577,96 +579,99 @@ Executable supports the following keyword arguments. Note that just
 like the positional arguments above, these keyword arguments can also
 be passed to [shared and static libraries](#library).
 
-- `<languagename>_pch` precompiled header file to use for the given language
-- `<languagename>_args` compiler flags to use for the given language;
+- `<languagename>_pch`: precompiled header file to use for the given language
+- `<languagename>_args`: compiler flags to use for the given language;
   eg: `cpp_args` for C++
-- `build_by_default` causes, when set to true, to have this target be
-  built by default, that is, when invoking plain `ninja`, the default
-  value is true for all built target types, since 0.38.0
-- `build_rpath` a string to add to target's rpath definition in the
+- `build_by_default` *(since 0.38.0)*: causes, when set to true, to
+   have this target be built by default. This means it will be built when
+  `meson compile` is called without any arguments. The default value is
+  `true` for all built target types.
+- `build_rpath`: a string to add to target's rpath definition in the
   build dir, but which will be removed on install
-- `dependencies` one or more objects created with
+- `dependencies`: one or more objects created with
   [`dependency`](#dependency) or [`find_library`](#compiler-object)
   (for external deps) or [`declare_dependency`](#declare_dependency)
   (for deps built by the project)
-- `extra_files` are not used for the build itself but are shown as
+- `extra_files`: not used for the build itself but are shown as
   source files in IDEs that group files by targets (such as Visual
   Studio)
-- `gui_app` when set to true flags this target as a GUI application on
-  platforms where this makes a difference (e.g. Windows)
-- `link_args` flags to use during linking. You can use UNIX-style
+- `gui_app`: when set to true flags this target as a GUI application on
+  platforms where this makes a difference (e.g. Windows).
+- `link_args`: flags to use during linking. You can use UNIX-style
   flags here for all platforms.
-- `link_depends` strings, files, or custom targets the link step
+- `link_depends`: strings, files, or custom targets the link step
   depends on such as a symbol visibility map. The purpose is to
   automatically trigger a re-link (but not a re-compile) of the target
   when this file changes.
-- `link_language` since 0.51.0 makes the linker for this target
-  be for the specified language. This is helpful for multi-language targets.
-- `link_whole` links all contents of the given static libraries
-  whether they are used by not, equivalent to the
-  `-Wl,--whole-archive` argument flag of GCC, available since 0.40.0.
-  As of 0.41.0 if passed a list that list will be flattened. Starting
-  from version 0.51.0 this argument also accepts outputs produced by
+- `link_language` *(since 0.51.0)* *(broken until 0.55.0)*: makes the linker for this
+  target be for the specified language. It is generally unnecessary to set
+  this, as meson will detect the right linker to use in most cases. There are
+  only two cases where this is needed. One, your main function in an
+  executable is not in the language meson picked, or second you want to force
+  a library to use only one ABI.
+- `link_whole` *(since 0.40.0)*: links all contents of the given static libraries
+  whether they are used by not, equivalent to the `-Wl,--whole-archive` argument flag of GCC.
+  *(since 0.41.0)* If passed a list that list will be flattened.
+  *(since 0.51.0)* This argument also accepts outputs produced by
   custom targets. The user must ensure that the output is a library in
   the correct format.
-- `link_with`, one or more shared or static libraries (built by this
-  project) that this target should be linked with, If passed a list
-  this list will be flattened as of 0.41.0. Starting with version
-  0.51.0, the arguments can also be custom targets. In this case Meson
-  will assume that merely adding the output file in the linker command
+- `link_with`: one or more shared or static libraries (built by this
+  project) that this target should be linked with. *(since 0.41.0)* If passed a 
+  list this list will be flattened. *(since 0.51.0)* The arguments can also be custom targets. 
+  In this case Meson will assume that merely adding the output file in the linker command
   line is sufficient to make linking work. If this is not sufficient,
   then the build system writer must write all other steps manually.
-- `export_dynamic` when set to true causes the target's symbols to be
+- `export_dynamic` *(since 0.45.0)*: when set to true causes the target's symbols to be
   dynamically exported, allowing modules built using the
   [`shared_module`](#shared_module) function to refer to functions,
   variables and other symbols defined in the executable itself. Implies
-  the `implib` argument.  Since 0.45.0
-- `implib` when set to true, an import library is generated for the
+  the `implib` argument.
+- `implib` *(since 0.42.0)*: when set to true, an import library is generated for the
   executable (the name of the import library is based on *exe_name*).
   Alternatively, when set to a string, that gives the base name for
   the import library.  The import library is used when the returned
   build target object appears in `link_with:` elsewhere.  Only has any
   effect on platforms where that is meaningful (e.g. Windows). Implies
-  the `export_dynamic` argument.  Since 0.42.0
-- `implicit_include_directories` is a boolean telling whether Meson
+  the `export_dynamic` argument.
+- `implicit_include_directories` *(since 0.42.0)*: a boolean telling whether Meson
   adds the current source and build directories to the include path,
-  defaults to `true`, since 0.42.0
-- `include_directories` one or more objects created with the
-  `include_directories` function, or, since 0.50.0, strings, which
+  defaults to `true`.
+- `include_directories`: one or more objects created with the
+  `include_directories` function, or *(since 0.50.0)* strings, which
   will be transparently expanded to include directory objects
-- `install`, when set to true, this executable should be installed, defaults to `false`
-- `install_dir` override install directory for this file. The value is
+- `install`: when set to true, this executable should be installed, defaults to `false`
+- `install_dir`: override install directory for this file. The value is
   relative to the `prefix` specified. F.ex, if you want to install
   plugins into a subdir, you'd use something like this: `install_dir :
   get_option('libdir') / 'projectname-1.0'`.
-- `install_mode` *(added 0.47.0)* specify the file mode in symbolic format
+- `install_mode` *(since 0.47.0)*: specify the file mode in symbolic format
   and optionally the owner/uid and group/gid for the installed files.
-- `install_rpath` a string to set the target's rpath to after install
+- `install_rpath`: a string to set the target's rpath to after install
   (but *not* before that). On Windows, this argument has no effect.
-- `objects` list of prebuilt object files (usually for third party
+- `objects`: list of prebuilt object files (usually for third party
   products you don't have source to) that should be linked in this
   target, **never** use this for object files that you build yourself.
-- `name_suffix` the string that will be used as the extension for the
+- `name_suffix`: the string that will be used as the extension for the
   target by overriding the default. By default on Windows this is
   `exe` and on other platforms it is omitted. Set this to `[]`, or omit
   the keyword argument for the default behaviour.
-- `override_options` takes an array of strings in the same format as
+- `override_options` *(since 0.40.0)*: takes an array of strings in the same format as
   `project`'s `default_options` overriding the values of these options
-  for this target only, since 0.40.0.
-- `gnu_symbol_visibility` specifies how symbols should be exported, see
+  for this target only.
+- `gnu_symbol_visibility` *(since 0.48.0)*: specifies how symbols should be exported, see
   e.g [the GCC Wiki](https://gcc.gnu.org/wiki/Visibility) for more
   information. This value can either be an empty string or one of
   `default`, `internal`, `hidden`, `protected` or `inlineshidden`, which
   is the same as `hidden` but also includes things like C++ implicit
   constructors as specified in the GCC manual. Ignored on compilers that
-  do not support GNU visibility arguments. Available since 0.48.0.
-- `d_import_dirs` list of directories to look in for string imports used
+  do not support GNU visibility arguments.
+- `d_import_dirs`: list of directories to look in for string imports used
   in the D programming language
-- `d_unittest`, when set to true, the D modules are compiled in debug mode
-- `d_module_versions` list of module version identifiers set when compiling D sources
-- `d_debug` list of module debug identifiers set when compiling D sources
-- `pie` *(added 0.49.0)* build a position-independent executable
-- `native`, is a boolean controlling whether the target is compiled for the
+- `d_unittest`: when set to true, the D modules are compiled in debug mode
+- `d_module_versions`: list of module version identifiers set when compiling D sources
+- `d_debug`: list of module debug identifiers set when compiling D sources
+- `pie` *(since 0.49.0)*: build a position-independent executable
+- `native`: is a boolean controlling whether the target is compiled for the
   build or host machines. Defaults to false, building for the host machine.
 
 The list of `sources`, `objects`, and `dependencies` is always
@@ -678,7 +683,7 @@ The returned object also has methods that are documented in the
 
 ### find_library()
 
-This function is deprecated and in the 0.31.0 release it was moved to
+*(since 0.31.0)* **(deprecated)** Use `find_library()` method of
 [the compiler object](#compiler-object) as obtained from
 `meson.get_compiler(lang)`.
 
@@ -692,12 +697,11 @@ This function is deprecated and in the 0.31.0 release it was moved to
 to be searched for in `PATH`, or a script in the current source
 directory.
 
-`program_name2` and later positional arguments are used as fallback
+*(since 0.37.0)* `program_name2` and later positional arguments are used as fallback
 strings to search for. This is meant to be used for cases where the
 program may have many alternative names, such as `foo` and
 `foo.py`. The function will check for the arguments one by one and the
-first one that is found is returned. Meson versions earlier than
-0.37.0 only accept one argument.
+first one that is found is returned.
 
 Keyword arguments are the following:
 
@@ -705,21 +709,21 @@ Keyword arguments are the following:
   abort if no program can be found. If `required` is set to `false`,
   Meson continue even if none of the programs can be found. You can
   then use the `.found()` method on the [returned object](#external-program-object) to check
-  whether it was found or not. Since *0.47.0*  the value of a
+  whether it was found or not. *(since 0.47.0)* The value of a
   [`feature`](Build-options.md#features) option can also be passed to the
   `required` keyword argument.
 
-- `native` *(since 0.43)* defines how this executable should be searched. By default
+- `native` *(since 0.43.0)*: defines how this executable should be searched. By default
   it is set to `false`, which causes Meson to first look for the
   executable in the cross file (when cross building) and if it is not
   defined there, then from the system. If set to `true`, the cross
   file is ignored and the program is only searched from the system.
 
-- `disabler` if `true` and the program couldn't be found, return a
+- `disabler` *(since 0.49.0)*: if `true` and the program couldn't be found, return a
   [disabler object](#disabler-object) instead of a not-found object.
-  *Since 0.49.0*
+  
 
-- `version` *(since 0.52.0)* Specifies the required version, see
+- `version` *(since 0.52.0)*: specifies the required version, see
   [`dependency()`](#dependency) for argument format. The version of the program
   is determined by running `program_name --version` command. If stdout is empty
   it fallbacks to stderr. If the output contains more text than simply a version
@@ -727,7 +731,7 @@ Keyword arguments are the following:
   If the output is more complicated than that, the version checking will have to
   be done manually using [`run_command()`](#run_command).
 
-- `dirs` *(since 0.53.0)* Extra list of absolute paths where to look for program
+- `dirs` *(since 0.53.0)*: extra list of absolute paths where to look for program
   names.
 
 Meson will also autodetect scripts with a shebang line and run them
@@ -795,22 +799,22 @@ argument is the executable to use. It can either be a self-built
 executable or one returned by find_program. Keyword arguments are the
 following:
 
-- `arguments` a list of template strings that will be the command line
+- `arguments`: a list of template strings that will be the command line
   arguments passed to the executable
-- `depends` is an array of build targets that must be built before this
+- `depends` *(since 0.51.0)*: is an array of build targets that must be built before this
   generator can be run. This is used if you have a generator that calls
-  a second executable that is built in this project. Available since 0.51.0
-- `depfile` is a template string pointing to a dependency file that a
+  a second executable that is built in this project.
+- `depfile`: is a template string pointing to a dependency file that a
   generator can write listing all the additional files this target
   depends on, for example a C compiler would list all the header files
   it included, and a change in any one of these files triggers a
   recompilation
-- `output` a template string (or list of template strings) defining
+- `output`: a template string (or list of template strings) defining
   how an output file name is (or multiple output names are) generated
   from a single source file name
-- `capture` when this argument is set to true, Meson captures `stdout`
-  of the `executable` and writes it to the target file specified as
-  `output`. Available since v0.43.0.
+- `capture` *(since 0.43.0)*: when this argument is set to true, Meson
+  captures `stdout` of the `executable` and writes it to the target file
+  specified as `output`.
 
 The returned object also has methods that are documented in the
 [object methods section](#generator-object) below.
@@ -973,13 +977,13 @@ except Visual Studio).
 Installs files from the source tree that are listed as positional
 arguments. The following keyword arguments are supported:
 
-- `install_dir` the absolute or relative path to the installation
+- `install_dir`: the absolute or relative path to the installation
   directory. If this is a relative path, it is assumed to be relative
   to the prefix.
 
-  If omitted, the directory defaults to `{datadir}/{projectname}` *(added 0.45.0)*.
+  If omitted, the directory defaults to `{datadir}/{projectname}` *(since 0.45.0)*.
 
-- `install_mode` specify the file mode in symbolic format and
+- `install_mode`: specify the file mode in symbolic format and
   optionally the owner/uid and group/gid for the installed files. For
   example:
 
@@ -991,10 +995,10 @@ arguments. The following keyword arguments are supported:
 
  To leave any of these three as the default, specify `false`.
 
-- `rename` if specified renames each source file into corresponding
+- `rename` *(since 0.46.0)*: if specified renames each source file into corresponding
   file from `rename` list. Nested paths are allowed and they are
   joined with `install_dir`. Length of `rename` list must be equal to
-  the number of sources.  *(added 0.46.0)*
+  the number of sources.
 
 See [Installing](Installing.md) for more examples.
 
@@ -1031,10 +1035,11 @@ This will install `common.h` and `kola.h` into `/{prefix}/cust/myproj`:
 install_headers('common.h', 'proj/kola.h', install_dir : 'cust', subdir : 'myproj')
 ```
 
-The `install_mode` argument can be used to specify the file mode in symbolic
-format and optionally the owner/uid and group/gid for the installed files.
-An example value could be `['rwxr-sr-x', 'root', 'root']`.
-*(Added 0.47.0)*.
+Accepts the following keywords:
+
+- `install_mode` *(since 0.47.0)*: can be used to specify the file mode in symbolic
+  format and optionally the owner/uid and group/gid for the installed files.
+  An example value could be `['rwxr-sr-x', 'root', 'root']`.
 
 ### install_man()
 
@@ -1047,12 +1052,13 @@ man directory during the install step. This directory can be
 overridden by specifying it with the `install_dir` keyword
 argument.
 
-The `install_mode` argument can be used to specify the file mode in symbolic
-format and optionally the owner/uid and group/gid for the installed files.
-An example value could be `['rwxr-sr-x', 'root', 'root']`.
-*(Added 0.47.0)*.
+Accepts the following keywords:
+
+- `install_mode` *(since 0.47.0)*: can be used to specify the file mode in symbolic
+  format and optionally the owner/uid and group/gid for the installed files.
+  An example value could be `['rwxr-sr-x', 'root', 'root']`.
 
-Since 0.49.0, [manpages are no longer compressed implicitly][install_man_49].
+*(since 0.49.0)* [manpages are no longer compressed implicitly][install_man_49].
 
 [install_man_49]: https://mesonbuild.com/Release-notes-for-0-49-0.html#manpages-are-no-longer-compressed-implicitly
 
@@ -1073,11 +1079,10 @@ The following keyword arguments are supported:
 - `exclude_directories`: a list of directory names that should not be installed.
   Names are interpreted as paths relative to the `subdir_name` location.
 - `install_dir`: the location to place the installed subdirectory.
-- `install_mode`: the file mode in symbolic format and optionally
-  the owner/uid and group/gid for the installed files. *(Added 0.47.0)*
-- `strip_directory`: install directory contents. `strip_directory=false` by default.
+- `install_mode` *(since 0.47.0)*: the file mode in symbolic format and optionally
+  the owner/uid and group/gid for the installed files.
+- `strip_directory` *(since 0.45.0)*: install directory contents. `strip_directory=false` by default.
   If `strip_directory=true` only the last component of the source path is used.
-  Since 0.45.0
 
 For a given directory `foo`:
 ```text
@@ -1122,7 +1127,9 @@ share/
     bool is_disabler(var)
 ```
 
-Returns true if a variable is a disabler and false otherwise. Added in 0.52.0.
+*(since 0.52.0)*
+
+Returns true if a variable is a disabler and false otherwise.
 
 ### is_variable()
 
@@ -1149,6 +1156,8 @@ the jar with `java -jar file.jar`.
 string join_paths(string1, string2, ...)
 ```
 
+*(since 0.36.0)*
+
 Joins the given strings into a file system path segment. For example
 `join_paths('foo', 'bar')` results in `foo/bar`. If any one of the
 individual segments is an absolute path, all segments before it are
@@ -1157,9 +1166,7 @@ dropped. That means that `join_paths('foo', '/bar')` returns `/bar`.
 **Warning** Don't use `join_paths()` for sources in [`library`](#library) and
 [`executable`](#executable), you should use [`files`](#files) instead.
 
-*Added 0.36.0*
-
-Since 0.49.0 using the`/` operator on strings is equivalent to calling
+*(since 0.49.0)* Using the`/` operator on strings is equivalent to calling
 `join_paths`.
 
 ```meson
@@ -1189,12 +1196,12 @@ library basis using the [dependency()](#dependency)) `static` keyword.
 The keyword arguments for this are the same as for
 [`executable`](#executable) with the following additions:
 
-- `name_prefix` the string that will be used as the prefix for the
+- `name_prefix`: the string that will be used as the prefix for the
   target output filename by overriding the default (only used for
   libraries). By default this is `lib` on all platforms and compilers,
   except for MSVC shared libraries where it is omitted to follow
   convention, and Cygwin shared libraries where it is `cyg`.
-- `name_suffix` the string that will be used as the suffix for the
+- `name_suffix`: the string that will be used as the suffix for the
   target output filename by overriding the default (see also:
   [executable()](#executable)). By default, for shared libraries this
   is `dylib` on macOS, `dll` on Windows, and `so` everywhere else.
@@ -1202,7 +1209,7 @@ The keyword arguments for this are the same as for
   static libraries use the `lib` suffix, but we use `a` to avoid a
   potential name clash with shared libraries which also generate
   import libraries with a `lib` suffix.
-- `rust_crate_type` specifies the crate type for Rust
+- `rust_crate_type`: specifies the crate type for Rust
   libraries. Defaults to `dylib` for shared libraries and `rlib` for
   static libraries.
 
@@ -1220,7 +1227,7 @@ them for the default behaviour for each platform.
 
 This function prints its argument to stdout.
 
-**Since 0.54.0** Can take more more than one argument that will be separated by
+*(since 0.54.0)* Can take more more than one argument that will be separated by
 space.
 
 ### warning()
@@ -1229,11 +1236,11 @@ space.
     void warning(text)
 ```
 
-This function prints its argument to stdout prefixed with WARNING:.
+*(since 0.44.0)*
 
-*Added 0.44.0*
+This function prints its argument to stdout prefixed with WARNING:.
 
-**Since 0.54.0** Can take more more than one argument that will be separated by
+*(since 0.54.0)* Can take more more than one argument that will be separated by
 space.
 
 ### summary()
@@ -1243,6 +1250,8 @@ space.
     void summary(dictionary)
 ```
 
+*(since 0.53.0)*
+
 This function is used to summarize build configuration at the end of the build
 process. This function provides a way for projects (and subprojects) to report
 this information in a clear way.
@@ -1258,10 +1267,10 @@ pair doesn't appear twice. All sections will be collected and printed at
 the end of the configuration in the same order as they have been called.
 
 Keyword arguments:
-- `section` title to group a set of key/value pairs.
-- `bool_yn` if set to true, all boolean values will be replaced by green YES
+- `section`: title to group a set of key/value pairs.
+- `bool_yn`: if set to true, all boolean values will be replaced by green YES
   or red NO.
-- `list_sep` *Since 0.54.0* string used to separate list values (e.g. `', '`).
+- `list_sep` *(since 0.54.0)*: string used to separate list values (e.g. `', '`).
 
 Example:
 ```meson
@@ -1296,8 +1305,6 @@ My Project 1.0
                      True
 ```
 
-*Added 0.53.0*
-
 ### project()
 
 ``` meson
@@ -1308,7 +1315,7 @@ The first argument to this function must be a string defining the name
 of this project. It is followed by programming languages that the
 project uses. Supported values for languages are `c`, `cpp` (for
 `C++`), `cuda`, `d`, `objc`, `objcpp`, `fortran`, `java`, `cs` (for `C#`),
-`vala` and `rust`. Since version `0.40.0` the list of languages
+`vala` and `rust`. *(since 0.40.0)* The list of languages
 is optional.
 
 The project name can be any string you want, it's not used for
@@ -1320,40 +1327,40 @@ Library_.
 
 Project supports the following keyword arguments.
 
- - `default_options` takes an array of strings. The strings are in the
-   form `key=value` and have the same format as options to
-   `meson configure`. For example to set the default project type you would
-   set this: `default_options : ['buildtype=debugoptimized']`. Note
-   that these settings are only used when running Meson for the first
-   time. Global options such as `buildtype` can only be specified in
-   the master project, settings in subprojects are ignored. Project
-   specific options are used normally even in subprojects.
-
-
-  - `license` takes a string or array of strings describing the
-    license(s) the code is under. Usually this would be something like
-    `license : 'GPL2+'`, but if the code has multiple licenses you can
-    specify them as an array like this: `license : ['proprietary',
-    'GPL3']`. Note that the text is informal and is only written to
-    the dependency manifest. Meson does not do any license validation,
-    you are responsible for verifying that you abide by all licensing
-    terms. You can access the value in your Meson build files with
-    `meson.project_license()`.
-
-  - `meson_version` takes a string describing which Meson version the
-    project requires. Usually something like `>=0.28.0`.
-
-  - `subproject_dir` specifies the top level directory name that holds
-    Meson subprojects. This is only meant as a compatibility option
-    for existing code bases that house their embedded source code in a
-    custom directory. All new projects should not set this but instead
-    use the default value. It should be noted that this keyword
-    argument is ignored inside subprojects. There can be only one
-    subproject dir and it is set in the top level Meson file.
-
- - `version`, which is a free form string describing the version of
-   this project. You can access the value in your Meson build files
-   with `meson.project_version()`.
+- `default_options`: takes an array of strings. The strings are in the
+  form `key=value` and have the same format as options to
+  `meson configure`. For example to set the default project type you would
+  set this: `default_options : ['buildtype=debugoptimized']`. Note
+  that these settings are only used when running Meson for the first
+  time. Global options such as `buildtype` can only be specified in
+  the master project, settings in subprojects are ignored. Project
+  specific options are used normally even in subprojects.
+
+
+- `license`: takes a string or array of strings describing the
+  license(s) the code is under. Usually this would be something like
+  `license : 'GPL2+'`, but if the code has multiple licenses you can
+  specify them as an array like this: `license : ['proprietary',
+  'GPL3']`. Note that the text is informal and is only written to
+  the dependency manifest. Meson does not do any license validation,
+  you are responsible for verifying that you abide by all licensing
+  terms. You can access the value in your Meson build files with
+  `meson.project_license()`.
+
+- `meson_version`: takes a string describing which Meson version the
+  project requires. Usually something like `>=0.28.0`.
+
+- `subproject_dir`: specifies the top level directory name that holds
+  Meson subprojects. This is only meant as a compatibility option
+  for existing code bases that house their embedded source code in a
+  custom directory. All new projects should not set this but instead
+  use the default value. It should be noted that this keyword
+  argument is ignored inside subprojects. There can be only one
+  subproject dir and it is set in the top level Meson file.
+
+- `version`: which is a free form string describing the version of
+  this project. You can access the value in your Meson build files
+  with `meson.project_version()`.
 
 ### run_command()
 
@@ -1375,15 +1382,13 @@ respectively.
 
 This function supports the following keyword arguments:
 
- - `check` takes a boolean. If `true`, the exit status code of the command will
+ - `check` *(since 0.47.0)*: takes a boolean. If `true`, the exit status code of the command will
    be checked, and the configuration will fail if it is non-zero. The default is
    `false`.
-   Since 0.47.0
- - `env` environment variables to set, such as `['NAME1=value1',
+ - `env` *(since 0.50.0)*: environment variables to set, such as `['NAME1=value1',
    'NAME2=value2']`, or an [`environment()`
    object](#environment-object) which allows more sophisticated
-   environment juggling. *Since 0.52.0* a dictionary is also accepted.
-   Since 0.50.0
+   environment juggling. *(since 0.52.0)* A dictionary is also accepted.
 
 See also [External commands](External-commands.md).
 
@@ -1395,8 +1400,8 @@ runtarget run_target(target_name, ...)
 
 This function creates a new top-level target that runs a specified
 command with the specified arguments. Like all top-level targets, this
-integrates with the selected backend. For instance, with Ninja you can
-run it as `ninja target_name`. Note that a run target produces no
+integrates with the selected backend. For instance, you can
+run it as `meson compile target_name`. Note that a run target produces no
 output as far as Meson is concerned. It is only meant for tasks such
 as running a code formatter or flashing an external device's firmware
 with a built file.
@@ -1424,8 +1429,7 @@ and subdirectory the target was defined in, respectively.
 Assigns a value to the given variable name. Calling
 `set_variable('foo', bar)` is equivalent to `foo = bar`.
 
-**Note:** Prior to v0.46.1, the `value` parameter could not be an
-array type, due to flattening of the function parameters.
+*(since 0.46.1)* The `value` parameter can be an array type.
 
 ### shared_library()
 
@@ -1437,7 +1441,7 @@ Builds a shared library with the given sources. Positional and keyword
 arguments are the same as for [`library`](#library) with the following
 extra keyword arguments.
 
-- `soversion` a string specifying the soversion of this shared
+- `soversion`: a string specifying the soversion of this shared
   library, such as `0`. On Linux and Windows this is used to set the
   soversion (or equivalent) in the filename. For example, if
   `soversion` is `4`, a Windows DLL will be called `foo-4.dll` and one
@@ -1445,19 +1449,19 @@ extra keyword arguments.
   `libfoo.so.4`. If this is not specified, the first part of `version`
   is used instead (see below). For example, if `version` is `3.6.0` and
   `soversion` is not defined, it is set to `3`.
-- `version` a string specifying the version of this shared library,
+- `version`: a string specifying the version of this shared library,
   such as `1.1.0`. On Linux and OS X, this is used to set the shared
   library version in the filename, such as `libfoo.so.1.1.0` and
   `libfoo.1.1.0.dylib`. If this is not specified, `soversion` is used
   instead (see above).
-- `darwin_versions` *(added 0.48)* an integer, string, or a list of
+- `darwin_versions` *(since 0.48.0)*: an integer, string, or a list of
   versions to use for setting dylib `compatibility version` and
   `current version` on macOS. If a list is specified, it must be
   either zero, one, or two elements. If only one element is specified
   or if it's not a list, the specified value will be used for setting
   both compatibility version and current version. If unspecified, the
   `soversion` will be used as per the aforementioned rules.
-- `vs_module_defs` a string, a File object, or Custom Target for a
+- `vs_module_defs`: a string, a File object, or Custom Target for a
   Microsoft module definition file for controlling symbol exports,
   etc., on platforms where that is possible (e.g. Windows).
 
@@ -1467,6 +1471,8 @@ extra keyword arguments.
     buildtarget shared_module(module_name, list_of_sources, ...)
 ```
 
+*(since 0.37.0)*
+
 Builds a shared module with the given sources. Positional and keyword
 arguments are the same as for [`library`](#library).
 
@@ -1481,7 +1487,7 @@ you will need to set the `export_dynamic` argument of the executable to
 
 Supports the following extra keyword arguments:
 
-- `vs_module_defs`, *(Added 0.52.0)*, a string, a File object, or
+- `vs_module_defs` *(since 0.52.0)*: a string, a File object, or
   Custom Target for a Microsoft module definition file for controlling
   symbol exports, etc., on platforms where that is possible
   (e.g. Windows).
@@ -1491,8 +1497,6 @@ platforms, notably OSX.  Consider using a
 [`shared_library`](#shared_library) instead, if you need to both
 `dlopen()` and link with a library.
 
-*Added 0.37.0*
-
 ### static_library()
 
 ``` meson
@@ -1503,7 +1507,7 @@ Builds a static library with the given sources. Positional and keyword
 arguments are otherwise the same as for [`library`](#library), but it
 has one argument the others don't have:
 
- - `pic`, *(Added 0.36.0)* builds the library as positional
+ - `pic` *(since 0.36.0)*: builds the library as positional
    independent code (so it can be linked into a shared library). This
    option has no effect on Windows and OS X since it doesn't make
    sense on Windows and PIC cannot be disabled on OS X.
@@ -1526,7 +1530,7 @@ and must only be executed once.
 
 This function has one keyword argument.
 
- - `if_found` takes one or several dependency objects and will only
+ - `if_found`: takes one or several dependency objects and will only
    recurse in the subdir if they all return `true` when queried with
    `.found()`
 
@@ -1571,16 +1575,15 @@ example a subproject called `foo` must be located in
 `${MESON_SOURCE_ROOT}/subprojects/foo`. Supports the following keyword
 arguments:
 
- - `default_options` *(added 0.37.0)* an array of default option values
+ - `default_options` *(since 0.37.0)*: an array of default option values
    that override those set in the subproject's `meson_options.txt`
    (like `default_options` in `project`, they only have effect when
    Meson is run for the first time, and command line arguments override
-   any default options in build files). *Since 0.54.0* `default_library`
+   any default options in build files). *(since 0.54.0)*: `default_library`
    built-in option can also be overridden.
- - `version` keyword argument that works just like the one in
-   `dependency`. It specifies what version the subproject should be,
-   as an example `>=1.0.1`
- - `required` *(added 0.48.0)* By default, `required` is `true` and
+ - `version`: works just like the same as in `dependency`.
+   It specifies what version the subproject should be, as an example `>=1.0.1`
+ - `required` *(since 0.48.0)*: By default, `required` is `true` and
    Meson will abort if the subproject could not be setup. You can set
    this to `false` and then use the `.found()` method on the [returned
    object](#subproject-object). You may also pass the value of a
@@ -1609,6 +1612,13 @@ object](#build-target-object) returned by
 object](#external-program-object) returned by
 [`find_program()`](#find_program).
 
+*(since 0.55.0)* When cross compiling, if an exe_wrapper is needed and defined
+the environment variable `MESON_EXE_WRAPPER` will be set to the string value
+of that wrapper (implementation detail: using `mesonlib.join_args`). Test
+scripts may use this to run cross built binaries. If your test needs
+`MESON_EXE_WRAPPER` in cross build situations it is your responsibility to
+return code 77 to tell the harness to report "skip".
+
 By default, environment variable
 [`MALLOC_PERTURB_`](http://man7.org/linux/man-pages/man3/mallopt.3.html)
 is automatically set by `meson test` to a random value between 1..255.
@@ -1629,50 +1639,52 @@ test(..., env: nomalloc, ...)
 
 #### test() Keyword arguments
 
-- `args` arguments to pass to the executable
+- `args`: arguments to pass to the executable
 
-- `env` environment variables to set, such as `['NAME1=value1',
+- `env`: environment variables to set, such as `['NAME1=value1',
   'NAME2=value2']`, or an [`environment()`
   object](#environment-object) which allows more sophisticated
-  environment juggling. *Since 0.52.0* a dictionary is also accepted.
+  environment juggling. *(since 0.52.0)* A dictionary is also accepted.
 
-- `is_parallel` when false, specifies that no other test must be
+- `is_parallel`: when false, specifies that no other test must be
   running at the same time as this test
 
-- `should_fail` when true the test is considered passed if the
+- `should_fail`: when true the test is considered passed if the
   executable returns a non-zero return value (i.e. reports an error)
 
-- `suite` `'label'` (or list of labels `['label1', 'label2']`)
+- `suite`: `'label'` (or list of labels `['label1', 'label2']`)
   attached to this test. The suite name is qualified by a (sub)project
   name resulting in `(sub)project_name:label`. In the case of a list
   of strings, the suite names will be `(sub)project_name:label1`,
   `(sub)project_name:label2`, etc.
 
-- `timeout` the amount of seconds the test is allowed to run, a test
+- `timeout`: the amount of seconds the test is allowed to run, a test
   that exceeds its time limit is always considered failed, defaults to
   30 seconds
 
-- `workdir` absolute path that will be used as the working directory
+- `workdir`: absolute path that will be used as the working directory
   for the test
 
-- `depends` specifies that this test depends on the specified
+- `depends` *(since 0.46.0)*: specifies that this test depends on the specified
   target(s), even though it does not take any of them as a command
   line argument. This is meant for cases where test finds those
   targets internally, e.g. plugins or globbing. Those targets are built
   before test is executed even if they have `build_by_default : false`.
-  Since 0.46.0
 
-- `protocol` specifies how the test results are parsed and can be one
-  of `exitcode` (the executable's exit code is used by the test harness
-  to record the outcome of the test) or `tap` ([Test Anything
-  Protocol](https://www.testanything.org/)). For more on the Meson test
-  harness protocol read [Unit Tests](Unit-tests.md). Since 0.50.0
+- `protocol` *(since 0.50.0)*: specifies how the test results are parsed and can
+  be one of `exitcode`, `tap`, or `gtest`. For more information about test
+  harness protocol read [Unit Tests](Unit-tests.md). The following values are
+  accepted:
+  - `exitcode`: the executable's exit code is used by the test harness
+    to record the outcome of the test).
+  - `tap`: [Test Anything Protocol](https://www.testanything.org/).
+  - `gtest` *(since 0.55.0)*: for Google Tests.
 
-- `priority` specifies the priority of a test. Tests with a
+- `priority` *(since 0.52.0)*:specifies the priority of a test. Tests with a
   higher priority are *started* before tests with a lower priority.
   The starting order of tests with identical priorities is
   implementation-defined. The default priority is 0, negative numbers are
-  permitted. Since 0.52.0
+  permitted.
 
 Defined tests can be run in a backend-agnostic way by calling
 `meson test` inside the build dir, or by using backend-specific
@@ -1688,15 +1700,15 @@ This command detects revision control commit information at build time
 and places it in the specified output file. This file is guaranteed to
 be up to date on every build. Keywords are similar to `custom_target`.
 
-- `command` string list with the command to execute, see
+- `command`: string list with the command to execute, see
   [`custom_target`](#custom_target) for details on how this command
   must be specified
-- `fallback` version number to use when no revision control
+- `fallback`: version number to use when no revision control
   information is present, such as when building from a release tarball
   (defaults to `meson.project_version()`)
-- `input` file to modify (e.g. `version.c.in`) (required)
-- `output` file to write the results to (e.g. `version.c`) (required)
-- `replace_string` string in the input file to substitute with the
+- `input`: file to modify (e.g. `version.c.in`) (required)
+- `output`: file to write the results to (e.g. `version.c`) (required)
+- `replace_string`: string in the input file to substitute with the
   commit information (defaults to `@VCS_TAG@`)
 
 Meson will read the contents of `input`, substitute the
@@ -1724,26 +1736,30 @@ The `meson` object allows you to introspect various properties of the
 system. This object is always mapped in the `meson` variable. It has
 the following methods.
 
-- `add_dist_script(script_name, arg1, arg, ...)` causes the script
+- `add_dist_script(script_name, arg1, arg2, ...)` *(since 0.48.0)*: causes the script
   given as argument to run during `dist` operation after the
   distribution source has been generated but before it is
   archived. Note that this runs the script file that is in the
   _staging_ directory, not the one in the source directory. If the
   script file can not be found in the staging directory, it is a hard
   error. This command can only invoked from the main project, calling
-  it from a subproject is a hard error. Available since 0.48.0. Before
-  0.49.0, the function only accepted a single argument. Since 0.54.0
-  the `MESON_SOURCE_ROOT` and `MESON_BUILD_ROOT` environment variables
-  are set when dist scripts are run.
+  it from a subproject is a hard error. *(since 0.49.0)* Accepts multiple arguments
+  for the fscript. *(since 0.54.0)* The `MESON_SOURCE_ROOT` and `MESON_BUILD_ROOT`
+  environment variables are set when dist scripts are run.
+  *(since 0.55.0)* The output of `configure_file`, `files`, and `find_program`
+  as well as strings.
 
-- `add_install_script(script_name, arg1, arg2, ...)` causes the script
+- `add_install_script(script_name, arg1, arg2, ...)`: causes the script
   given as an argument to be run during the install step, this script
   will have the environment variables `MESON_SOURCE_ROOT`,
   `MESON_BUILD_ROOT`, `MESON_INSTALL_PREFIX`,
   `MESON_INSTALL_DESTDIR_PREFIX`, and `MESONINTROSPECT` set.
   All positional arguments are passed as parameters.
+  *(since 0.55.0)* The output of `configure_file`, `files`, `find_program`,
+  `custom_target`, indexes of `custom_target`, `executable`, `library`, and
+  other built targets as well as strings.
 
-  *(added 0.54)* If `meson install` is called with the `--quiet` option, the
+  *(since 0.54.0)* If `meson install` is called with the `--quiet` option, the
   environment variable `MESON_INSTALL_QUIET` will be set.
 
   Meson uses the `DESTDIR` environment variable as set by the
@@ -1768,21 +1784,23 @@ the following methods.
   shell would. If your script uses Python, `shlex.split()` is the
   easiest correct way to do this.
 
-- `add_postconf_script(script_name, arg1, arg2, ...)` will run the
+- `add_postconf_script(script_name, arg1, arg2, ...)`: runs the
   executable given as an argument after all project files have been
   generated. This script will have the environment variables
   `MESON_SOURCE_ROOT` and `MESON_BUILD_ROOT` set.
+  *(since 0.55.0)* The output of `configure_file`, `files`, and `find_program`
+  as well as strings.
 
-- `backend()` *(added 0.37.0)* returns a string representing the
+- `backend()` *(since 0.37.0)*: returns a string representing the
   current backend: `ninja`, `vs2010`, `vs2015`, `vs2017`, `vs2019`,
   or `xcode`.
 
-- `build_root()` returns a string with the absolute path to the build
+- `build_root()`: returns a string with the absolute path to the build
   root directory. Note: this function will return the build root of
   the parent project if called from a subproject, which is usually
   not what you want. Try using `current_build_dir()`.
 
-- `source_root()` returns a string with the absolute path to the
+- `source_root()`: returns a string with the absolute path to the
   source root directory. Note: you should use the `files()` function
   to refer to files in the root source directory instead of
   constructing paths manually with `meson.source_root()`. This
@@ -1790,17 +1808,17 @@ the following methods.
   from a subproject, which is usually not what you want. Try using
   `current_source_dir()`.
 
-- `current_build_dir()` returns a string with the absolute path to the
+- `current_build_dir()`: returns a string with the absolute path to the
   current build directory.
 
-- `current_source_dir()` returns a string to the current source
+- `current_source_dir()`: returns a string to the current source
   directory. Note: **you do not need to use this function** when
   passing files from the current source directory to a function since
   that is the default. Also, you can use the `files()` function to
   refer to files in the current or any other source directory instead
   of constructing paths manually with `meson.current_source_dir()`.
 
-- `get_compiler(language)` returns [an object describing a
+- `get_compiler(language)`: returns [an object describing a
   compiler](#compiler-object), takes one positional argument which is
   the language to use. It also accepts one keyword argument, `native`
   which when set to true makes Meson return the compiler for the build
@@ -1809,49 +1827,52 @@ the following methods.
   returns the "cross" compiler if we're currently cross-compiling and
   the "native" compiler if we're not.
 
-- `get_cross_property(propname, fallback_value)`
-  *Consider get_external_property() instead*. Returns the given
+- `get_cross_property(propname, fallback_value)`:
+  *Consider `get_external_property()` instead*. Returns the given
   property from a cross file, the optional fallback_value is returned
   if not cross compiling or the given property is not found.
 
 - `get_external_property(propname, fallback_value, native: true/false)`
-  *(added 0.54.0)* returns the given property from a native or cross file.
+  *(since 0.54.0)*: returns the given property from a native or cross file.
   The optional fallback_value is returned if the given property is not found.
   The optional `native: true` forces retrieving a variable from the
   native file, even when cross-compiling.
   If `native: false` or not specified, variable is retrieved from the
   cross-file if cross-compiling, and from the native-file when not cross-compiling.
 
-- `has_exe_wrapper()` returns true when doing a cross build if there
-  is a wrapper command that can be used to execute cross built
-  binaries (for example when cross compiling from Linux to Windows,
-  one can use `wine` as the wrapper).
+- `can_run_host_binaries()` *(since 0.55.0)*: returns true if the build machine can run
+  binaries compiled for the host. This returns true unless you are
+  cross compiling, need a helper to run host binaries, and don't have one.
+  For example when cross compiling from Linux to Windows, one can use `wine`
+  as the helper.
+
+- `has_exe_wrapper()`: *(since 0.55.0)* **(deprecated)**. Use `can_run_host_binaries` instead.
 
-- `install_dependency_manifest(output_name)` installs a manifest file
+- `install_dependency_manifest(output_name)`: installs a manifest file
   containing a list of all subprojects, their versions and license
   files to the file name given as the argument.
 
-- `is_cross_build()` returns `true` if the current build is a [cross
+- `is_cross_build()`: returns `true` if the current build is a [cross
   build](Cross-compilation.md) and `false` otherwise.
 
-- `is_subproject()` returns `true` if the current project is being
+- `is_subproject()`: returns `true` if the current project is being
   built as a subproject of some other project and `false` otherwise.
 
-- `is_unity()` returns `true` when doing a [unity
+- `is_unity()`: returns `true` when doing a [unity
   build](Unity-builds.md) (multiple sources are combined before
   compilation to reduce build time) and `false` otherwise.
 
-- `override_find_program(progname, program)` [*(Added
-  0.46.0)*](Release-notes-for-0.46.0.md#can-override-find_program)
+- `override_find_program(progname, program)` *(since 0.46.0)*:
   specifies that whenever `find_program` is used to find a program
   named `progname`, Meson should not look it up on the system but
   instead return `program`, which may either be the result of
-  `find_program`, `configure_file` or `executable`.
+  `find_program`, `configure_file` or `executable`. *(since 0.55.0)* If a version
+  check is passed to `find_program` for a program that has been overridden with
+  an executable, the current project version is used.
 
   If `program` is an `executable`, it cannot be used during configure.
 
-- `override_dependency(name, dep_object)` [*(Added
-  0.54.0)*](Release-notes-for-0.54.0.md#override-dependency)
+- `override_dependency(name, dep_object)` *(since 0.54.0)*:
   specifies that whenever `dependency(name, ...)` is used, Meson should not
   look it up on the system but instead return `dep_object`, which may either be
   the result of `dependency()` or `declare_dependency()`. It takes optional
@@ -1859,16 +1880,16 @@ the following methods.
   project to retrieve the dependency without having to know the dependency
   variable name: `dependency(name, fallback : subproject_name)`.
 
-- `project_version()` returns the version string specified in
+- `project_version()`: returns the version string specified in
   `project` function call.
 
-- `project_license()` returns the array of licenses specified in
+- `project_license()`: returns the array of licenses specified in
   `project` function call.
 
-- `project_name()` returns the project name specified in the `project`
+- `project_name()`: returns the project name specified in the `project`
   function call.
 
-- `version()` return a string with the version of Meson.
+- `version()`: return a string with the version of Meson.
 
 ### `build_machine` object
 
@@ -1877,19 +1898,19 @@ doing the actual compilation. See
 [Cross-compilation](Cross-compilation.md). It has the following
 methods:
 
-- `cpu_family()` returns the CPU family name. [This
+- `cpu_family()`: returns the CPU family name. [This
   table](Reference-tables.md#cpu-families) contains all known CPU
   families. These are guaranteed to continue working.
 
-- `cpu()` returns a more specific CPU name, such as `i686`, `amd64`,
+- `cpu()`: returns a more specific CPU name, such as `i686`, `amd64`,
   etc.
 
-- `system()` returns the operating system name.  [This
+- `system()`: returns the operating system name.  [This
   table](Reference-tables.md#operating-system-names) Lists all of
   the currently known Operating System names, these are guaranteed to
   continue working.
 
-- `endian()` returns `big` on big-endian systems and `little` on
+- `endian()`: returns `big` on big-endian systems and `little` on
   little-endian systems.
 
 Currently, these values are populated using
@@ -1937,58 +1958,61 @@ the cross-info file, `host_machine` values are returned instead.
 All [strings](Syntax.md#strings) have the following methods. Strings
 are immutable, all operations return their results as a new string.
 
-- `contains(string)` returns true if string contains the string
-  specified as the argument
+- `contains(string)`: returns true if string contains the string
+  specified as the argument.
 
-- `endswith(string)` returns true if string ends with the string
-  specified as the argument
+- `endswith(string)`: returns true if string ends with the string
+  specified as the argument.
 
-- `format()` formats text, see the [Syntax
-  manual](Syntax.md#string-formatting) for usage info
+- `format()`: formats text, see the [Syntax
+  manual](Syntax.md#string-formatting) for usage info.
 
-- `join(list_of_strings)` is the opposite of split, for example
-  `'.'.join(['a', 'b', 'c']` yields `'a.b.c'`
+- `join(list_of_strings)`: the opposite of split, for example
+  `'.'.join(['a', 'b', 'c']` yields `'a.b.c'`.
 
-- `split(split_character)` splits the string at the specified
+- `split(split_character)`: splits the string at the specified
   character (or whitespace if not set) and returns the parts in an
-  array
+  array.
 
-- `startswith(string)` returns true if string starts with the string
+- `startswith(string)`: returns true if string starts with the string
   specified as the argument
 
-- `strip()` removes whitespace at the beginning and end of the string
-  *(added 0.43.0)* optionally can take one positional string argument,
-  and all characters in that string will be stripped
+- `substring(start,end)` *(since 0.56.0)*: returns a substring specified from start to end.
+  Both `start` and `end` arguments are optional, so, for example, `'foobar'.substring()` will return `'foobar'`.
 
-- `to_int` returns the string converted to an integer (error if string
-  is not a number)
+- `strip()`: removes whitespace at the beginning and end of the string.
+  *(since 0.43.0)* Optionally can take one positional string argument,
+  and all characters in that string will be stripped.
 
-- `to_lower()` creates a lower case version of the string
+- `to_int()`: returns the string converted to an integer (error if string
+  is not a number).
 
-- `to_upper()` creates an upper case version of the string
+- `to_lower()`: creates a lower case version of the string.
 
-- `underscorify()` creates a string where every non-alphabetical
-  non-number character is replaced with `_`
+- `to_upper()`: creates an upper case version of the string.
 
-- `version_compare(comparison_string)` does semantic version
+- `underscorify()`: creates a string where every non-alphabetical
+  non-number character is replaced with `_`.
+
+- `version_compare(comparison_string)`: does semantic version
   comparison, if `x = '1.2.3'` then `x.version_compare('>1.0.0')`
-  returns `true`
+  returns `true`.
 
 ### `Number` object
 
 [Numbers](Syntax.md#numbers) support these methods:
 
- - `is_even()` returns true if the number is even
- - `is_odd()` returns true if the number is odd
- - `to_string()` returns the value of the number as a string.
+- `is_even()`: returns true if the number is even
+- `is_odd()`: returns true if the number is odd
+- `to_string()`: returns the value of the number as a string.
 
 ### `boolean` object
 
 A [boolean](Syntax.md#booleans) object has two simple methods:
 
-- `to_int()` as above, but returns either `1` or `0`
+- `to_int()`: returns either `1` or `0`.
 
-- `to_string()` returns the string `'true'` if the boolean is true or
+- `to_string()`: returns the string `'true'` if the boolean is true or
   `'false'` otherwise. You can also pass it two strings as positional
   arguments to specify what to return for true/false. For instance,
   `bool.to_string('yes', 'no')` will return `yes` if the boolean is
@@ -1998,27 +2022,29 @@ A [boolean](Syntax.md#booleans) object has two simple methods:
 
 The following methods are defined for all [arrays](Syntax.md#arrays):
 
-- `contains(item)`, returns `true` if the array contains the object
+- `contains(item)`: returns `true` if the array contains the object
   given as argument, `false` otherwise
 
-- `get(index, fallback)`, returns the object at the given index,
+- `get(index, fallback)`: returns the object at the given index,
   negative indices count from the back of the array, indexing out of
-  bounds returns the `fallback` value *(added 0.38.0)* or, if it is
+  bounds returns the `fallback` value *(since 0.38.0)* or, if it is
   not specified, causes a fatal error
 
-- `length()`, the size of the array
+- `length()`: the size of the array
 
 You can also iterate over arrays with the [`foreach`
 statement](Syntax.md#foreach-statements).
 
 ### `dictionary` object
 
+*(since 0.47.0)*
+
 The following methods are defined for all [dictionaries](Syntax.md#dictionaries):
 
-- `has_key(key)` returns `true` if the dictionary contains the key
+- `has_key(key)`: returns `true` if the dictionary contains the key
   given as argument, `false` otherwise
 
-- `get(key, fallback)`, returns the value for the key given as first
+- `get(key, fallback)`: returns the value for the key given as first
   argument if it is present in the dictionary, or the optional
   fallback value given as the second argument. If a single argument
   was given and the key was not found, causes a fatal error
@@ -2026,9 +2052,7 @@ The following methods are defined for all [dictionaries](Syntax.md#dictionaries)
 You can also iterate over dictionaries with the [`foreach`
 statement](Syntax.md#foreach-statements).
 
-Dictionaries are available since 0.47.0.
-
-Since 0.48.0 dictionaries can be added (e.g. `d1 = d2 + d3` and `d1 += d2`).
+*(since 0.48.0)* Dictionaries can be added (e.g. `d1 = d2 + d3` and `d1 += d2`).
 Values from the second dictionary overrides values from the first.
 
 ## Returned objects
@@ -2042,204 +2066,202 @@ This object is returned by
 for a given language and allows you to query its properties. It has
 the following methods:
 
-- `alignment(typename)` returns the alignment of the type specified in
+- `alignment(typename)`: returns the alignment of the type specified in
   the positional argument, you can specify external dependencies to
   use with `dependencies` keyword argument.
 
-- `cmd_array()` returns an array containing the command arguments for
+- `cmd_array()`: returns an array containing the command arguments for
   the current compiler.
 
-- `compiles(code)` returns true if the code fragment given in the
+- `compiles(code)`: returns true if the code fragment given in the
   positional argument compiles, you can specify external dependencies
   to use with `dependencies` keyword argument, `code` can be either a
   string containing source code or a `file` object pointing to the
   source code.
 
-- `compute_int(expr, ...')` computes the value of the given expression
+- `compute_int(expr, ...')`: computes the value of the given expression
   (as an example `1 + 2`). When cross compiling this is evaluated with
   an iterative algorithm, you can specify keyword arguments `low`
   (defaults to -1024), `high` (defaults to 1024) and `guess` to
   specify max and min values for the search and the value to try
   first.
 
-- `find_library(lib_name, ...)` tries to find the library specified in
+- `find_library(lib_name, ...)`: tries to find the library specified in
   the positional argument. The [result
   object](#external-library-object) can be used just like the return
   value of `dependency`. If the keyword argument `required` is false,
   Meson will proceed even if the library is not found. By default the
   library is searched for in the system library directory
   (e.g. /usr/lib). This can be overridden with the `dirs` keyword
-  argument, which can be either a string or a list of strings.  Since
-  *0.47.0* the value of a [`feature`](Build-options.md#features)
+  argument, which can be either a string or a list of strings.
+  *(since 0.47.0)* The value of a [`feature`](Build-options.md#features)
   option can also be passed to the `required` keyword argument.
-  *Since 0.49.0* if the keyword argument `disabler` is `true` and the
+  *(since 0.49.0)* If the keyword argument `disabler` is `true` and the
   dependency couldn't be found, return a [disabler object](#disabler-object)
-  instead of a not-found dependency. *Since 0.50.0* the `has_headers` keyword
+  instead of a not-found dependency. *(since 0.50.0)* The `has_headers` keyword
   argument can be a list of header files that must be found as well, using
   `has_header()` method. All keyword arguments prefixed with `header_` will be
-  passed down to `has_header()` method with the prefix removed. *Since 0.51.0*
-  the `static` keyword (boolean) can be set to `true` to limit the search to
+  passed down to `has_header()` method with the prefix removed. *(since 0.51.0)*
+  The `static` keyword (boolean) can be set to `true` to limit the search to
   static libraries and `false` for dynamic/shared.
 
-- `first_supported_argument(list_of_strings)`, given a list of
+- `first_supported_argument(list_of_strings)`: given a list of
   strings, returns the first argument that passes the `has_argument`
   test or an empty array if none pass.
 
-- `first_supported_link_argument(list_of_strings)` *(added 0.46.0)*,
+- `first_supported_link_argument(list_of_strings)` *(since 0.46.0)*:
   given a list of strings, returns the first argument that passes the
   `has_link_argument` test or an empty array if none pass.
 
-- `get_define(definename)` returns the given preprocessor symbol's
+- `get_define(definename)`: returns the given preprocessor symbol's
   value as a string or empty string if it is not defined.
-  Starting with 0.47.0, this method will concatenate string literals as
+  *(since 0.47.0)* This method will concatenate string literals as
   the compiler would. E.g. `"a" "b"` will become `"ab"`.
 
-- `get_id()` returns a string identifying the compiler. For example,
+- `get_id()`: returns a string identifying the compiler. For example,
   `gcc`, `msvc`, [and more](Reference-tables.md#compiler-ids).
 
-- `get_argument_syntax()` *(new in 0.49.0)* returns a string identifying the type
+- `get_argument_syntax()` *(since 0.49.0)*: returns a string identifying the type
   of arguments the compiler takes. Can be one of `gcc`, `msvc`, or an undefined
   string value. This method is useful for identifying compilers that are not
   gcc or msvc, but use the same argument syntax as one of those two compilers
   such as clang or icc, especially when they use different syntax on different
   operating systems.
 
-- `get_linker_id()` *(added 0.53.0)* returns a string identifying the linker.
+- `get_linker_id()` *(since 0.53.0)*: returns a string identifying the linker.
    For example, `ld.bfd`, `link`, [and more](Reference-tables.md#linker-ids).
 
-- `get_supported_arguments(list_of_string)` *(added 0.43.0)* returns
+- `get_supported_arguments(list_of_string)` *(since 0.43.0)*: returns
   an array containing only the arguments supported by the compiler,
   as if `has_argument` were called on them individually.
 
-- `get_supported_link_arguments(list_of_string)` *(added 0.46.0)* returns
+- `get_supported_link_arguments(list_of_string)` *(since 0.46.0)*: returns
   an array containing only the arguments supported by the linker,
   as if `has_link_argument` were called on them individually.
 
-- `has_argument(argument_name)` returns true if the compiler accepts
+- `has_argument(argument_name)`: returns true if the compiler accepts
   the specified command line argument, that is, can compile code
   without erroring out or printing a warning about an unknown flag.
 
-- `has_link_argument(argument_name)` *(added 0.46.0)* returns true if
+- `has_link_argument(argument_name)` *(since 0.46.0)*: returns true if
   the linker accepts the specified command line argument, that is, can
   compile and link code without erroring out or printing a warning
   about an unknown flag. Link arguments will be passed to the
   compiler, so should usually have the `-Wl,` prefix. On VisualStudio
   a `/link` argument will be prepended.
 
-- `has_function(funcname)` returns true if the given function is
+- `has_function(funcname)`: returns true if the given function is
   provided by the standard library or a library passed in with the
   `args` keyword, you can specify external dependencies to use with
   `dependencies` keyword argument.
 
-- `check_header` *(added 0.47.0)* returns true if the specified header is *usable* with
+- `check_header` *(since 0.47.0)*: returns true if the specified header is *usable* with
   the specified prefix, dependencies, and arguments.
   You can specify external dependencies to use with `dependencies`
   keyword argument and extra code to put above the header test with
   the `prefix` keyword. In order to look for headers in a specific
   directory you can use `args : '-I/extra/include/dir`, but this
   should only be used in exceptional cases for includes that can't be
-  detected via pkg-config and passed via `dependencies`. Since *0.50.0* the
+  detected via pkg-config and passed via `dependencies`. *(since 0.50.0)* The
   `required` keyword argument can be used to abort if the header cannot be
   found.
 
-- `has_header` returns true if the specified header *exists*, and is
+- `has_header`: returns true if the specified header *exists*, and is
   faster than `check_header()` since it only does a pre-processor check.
   You can specify external dependencies to use with `dependencies`
   keyword argument and extra code to put above the header test with
   the `prefix` keyword. In order to look for headers in a specific
   directory you can use `args : '-I/extra/include/dir`, but this
   should only be used in exceptional cases for includes that can't be
-  detected via pkg-config and passed via `dependencies`. Since *0.50.0* the
+  detected via pkg-config and passed via `dependencies`. *(since 0.50.0)* The
   `required` keyword argument can be used to abort if the header cannot be
   found.
 
-- `has_header_symbol(headername, symbolname)` allows one to detect
+- `has_header_symbol(headername, symbolname)`: detects
   whether a particular symbol (function, variable, #define, type
   definition, etc) is declared in the specified header, you can
   specify external dependencies to use with `dependencies` keyword
-  argument. Since *0.50.0* the `required` keyword argument can be used to abort
-  if the symbol cannot be found.
+  argument. *(since 0.50.0)* The `required` keyword argument can be 
+  used to abort if the symbol cannot be found.
 
-- `has_member(typename, membername)` takes two arguments, type name
+- `has_member(typename, membername)`: takes two arguments, type name
   and member name and returns true if the type has the specified
   member, you can specify external dependencies to use with
   `dependencies` keyword argument.
 
-- `has_members(typename, membername1, membername2, ...)` takes at
+- `has_members(typename, membername1, membername2, ...)`: takes at
   least two arguments, type name and one or more member names, returns
   true if the type has all the specified members, you can specify
   external dependencies to use with `dependencies` keyword argument.
 
-- `has_multi_arguments(arg1, arg2, arg3, ...)` is the same as
+- `has_multi_arguments(arg1, arg2, arg3, ...)` *(since 0.37.0)*: the same as
   `has_argument` but takes multiple arguments and uses them all in a
-  single compiler invocation, available since 0.37.0.
+  single compiler invocation.
 
-- `has_multi_link_arguments(arg1, arg2, arg3, ...)` *(added 0.46.0)*
-  is the same as `has_link_argument` but takes multiple arguments and
+- `has_multi_link_arguments(arg1, arg2, arg3, ...)` *(since 0.46.0)*:
+  the same as `has_link_argument` but takes multiple arguments and
   uses them all in a single compiler invocation.
 
-- `has_type(typename)` returns true if the specified token is a type,
+- `has_type(typename)`: returns true if the specified token is a type,
   you can specify external dependencies to use with `dependencies`
   keyword argument.
 
-- `links(code)` returns true if the code fragment given in the
+- `links(code)`: returns true if the code fragment given in the
   positional argument compiles and links, you can specify external
   dependencies to use with `dependencies` keyword argument, `code` can
   be either a string containing source code or a `file` object
   pointing to the source code.
 
-- `run(code)` attempts to compile and execute the given code fragment,
+- `run(code)`: attempts to compile and execute the given code fragment,
   returns a run result object, you can specify external dependencies
   to use with `dependencies` keyword argument, `code` can be either a
   string containing source code or a `file` object pointing to the
   source code.
 
-- `symbols_have_underscore_prefix()` returns `true` if the C symbol
-  mangling is one underscore (`_`) prefixed to the symbol, available
-  since 0.37.0.
+- `symbols_have_underscore_prefix()` *(since 0.37.0)*: returns `true`
+  if the C symbol mangling is one underscore (`_`) prefixed to the symbol.
 
-- `sizeof(typename, ...)` returns the size of the given type
+- `sizeof(typename, ...)`: returns the size of the given type
   (e.g. `'int'`) or -1 if the type is unknown, to add includes set
   them in the `prefix` keyword argument, you can specify external
   dependencies to use with `dependencies` keyword argument.
 
-- `version()` returns the compiler's version number as a string.
+- `version()`: returns the compiler's version number as a string.
 
-- `has_function_attribute(name)` *(added in 0.48.0)* returns `true` if the
+- `has_function_attribute(name)` *(since 0.48.0)*: returns `true` if the
   compiler supports the GNU style (`__attribute__(...)`) `name`. This is
   preferable to manual compile checks as it may be optimized for compilers that
   do not support such attributes.
   [This table](Reference-tables.md#gcc-__attribute__) lists all of the
   supported attributes.
 
-- `get_supported_function_attributes(list_of_names)` *(added in 0.48.0)*
+- `get_supported_function_attributes(list_of_names)` *(since 0.48.0)*:
   returns an array containing any names that are supported GCC style
   attributes. Equivalent to `has_function_attribute` was called on each of them
   individually.
 
 The following keyword arguments can be used:
 
-- `args` can be used to pass a list of compiler arguments that are
+- `args`: used to pass a list of compiler arguments that are
   required to find the header or symbol. For example, you might need
   to pass the include path `-Isome/path/to/header` if a header is not
-  in the default include path. In versions newer than 0.38.0 you
-  should use the `include_directories` keyword described below. You
-  may also want to pass a library name `-lfoo` for `has_function` to
-  check for a function. Supported by all methods except `get_id`,
-  `version`, and `find_library`.
+  in the default include path. *(since 0.38.0)* you should use the
+  `include_directories` keyword described below. You may also want to
+  pass a library name `-lfoo` for `has_function` to check for a function.
+  Supported by all methods except `get_id`, `version`, and `find_library`.
 
-- `include_directories` specifies extra directories for header
-  searches. *(added 0.38.0)*
+- `include_directories` *(since 0.38.0)*: specifies extra directories for 
+  header searches.
 
-- `name` the name to use for printing a message about the compiler
+- `name`: the name to use for printing a message about the compiler
   check. Supported by the methods `compiles()`, `links()`, and
   `run()`. If this keyword argument is not passed to those methods, no
   message will be printed about the check.
 
-- `no_builtin_args` when set to true, the compiler arguments controlled
+- `no_builtin_args`: when set to true, the compiler arguments controlled
   by built-in configuration options are not added.
 
-- `prefix` can be used to add #includes and other things that are
+- `prefix`: adds #includes and other things that are
   required for the symbol to be declared. System definitions should be
   passed via compiler args (eg: `_GNU_SOURCE` is often required for
   some symbols to be exposed on Linux, and it should be passed via
@@ -2270,15 +2292,15 @@ A build target is either an [executable](#executable),
 [both shared and static library](#both_libraries) or
 [shared module](#shared_module).
 
-- `extract_all_objects()` is same as `extract_objects` but returns all
-  object files generated by this target. Since 0.46.0 keyword argument
+- `extract_all_objects()`: is same as `extract_objects` but returns all
+  object files generated by this target. *(since 0.46.0)* keyword argument
   `recursive` must be set to `true` to also return objects passed to
   the `object` argument of this target. By default only objects built
   for this target are returned to maintain backward compatibility with
   previous versions.  The default will eventually be changed to `true`
   in a future version.
 
-- `extract_objects(source1, source2, ...)` takes as its arguments
+- `extract_objects(source1, source2, ...)`: takes as its arguments
   a number of source files as [`string`](#string-object) or
   [`files()`](#files) and returns an opaque value representing the
   object files generated for those source files. This is typically used
@@ -2286,17 +2308,17 @@ A build target is either an [executable](#executable),
   some source files with custom flags. To use the object file(s)
   in another build target, use the `objects:` keyword argument.
 
-- `full_path()` returns a full path pointing to the result target file.
+- `full_path()`: returns a full path pointing to the result target file.
   NOTE: In most cases using the object itself will do the same job as
   this and will also allow Meson to setup inter-target dependencies
   correctly. Please file a bug if that doesn't work for you.
 
-- `private_dir_include()` returns a opaque value that works like
+- `private_dir_include()`: returns a opaque value that works like
   `include_directories` but points to the private directory of this
   target, usually only needed if an another target needs to access
   some generated internal headers of this target
 
-- `name()` *Since 0.54.0*, returns the target name.
+- `name()` *(since 0.54.0)*: returns the target name.
 
 
 ### `configuration` data object
@@ -2307,20 +2329,19 @@ configuration values to be used for generating configuration files. A
 more in-depth description can be found in the [the configuration wiki
 page](Configuration.md) It has three methods:
 
-- `get(varname, default_value)` returns the value of `varname`, if the
+- `get(varname, default_value)`: returns the value of `varname`, if the
   value has not been set returns `default_value` if it is defined
-  *(added 0.38.0)* and errors out if not
+  *(since 0.38.0)* and errors out if not
 
-- `get_unquoted(varname, default_value)` returns the value of `varname`
-  but without surrounding double quotes (`"`). If the value has not been
-  set returns `default_value` if it is defined and errors out if not.
-  Available since 0.44.0
+- `get_unquoted(varname, default_value)` *(since 0.44.0)*: returns the value
+  of `varname` but without surrounding double quotes (`"`). If the value has
+  not been set returns `default_value` if it is defined and errors out if not.
 
-- `has(varname)`, returns `true` if the specified variable is set
+- `has(varname)`: returns `true` if the specified variable is set
 
-- `merge_from(other)` takes as argument a different configuration data
-  object and copies all entries from that object to the current
-  object, available since 0.42.0
+- `merge_from(other)` *(since 0.42.0)*: takes as argument a different 
+  configuration data object and copies all entries from that object to 
+  the current.
 
 - `set(varname, value)`, sets a variable to a given value
 
@@ -2342,20 +2363,20 @@ cause a syntax error.
 This object is returned by [`custom_target`](#custom_target) and
 contains a target with the following methods:
 
-- `full_path()` returns a full path pointing to the result target file
+- `full_path()`: returns a full path pointing to the result target file
   NOTE: In most cases using the object itself will do the same job as
   this and will also allow Meson to setup inter-target dependencies
   correctly. Please file a bug if that doesn't work for you.
-  *Since 0.54.0* it can be also called on indexes objects:
+  *(since 0.54.0)* It can be also called on indexes objects:
   `custom_targets[i].full_path()`.
 
-- `[index]` returns an opaque object that references this target, and
+- `[index]`: returns an opaque object that references this target, and
   can be used as a source in other targets. When it is used as such it
   will make that target depend on this custom target, but the only
   source added will be the one that corresponds to the index of the
   custom target's output argument.
 
-- `to_list()` *Since 0.54.0*, returns a list of opaque objects that references
+- `to_list()` *(since 0.54.0)*: returns a list of opaque objects that references
   this target, and can be used as a source in other targets. This can be used to
   iterate outputs with `foreach` loop.
 
@@ -2364,48 +2385,48 @@ contains a target with the following methods:
 This object is returned by [`dependency()`](#dependency) and contains
 an external dependency with the following methods:
 
- - `found()` which returns whether the dependency was found
+ - `found()`: returns whether the dependency was found.
 
- - `name()` *(Added 0.48.0)* returns the name of the dependency that was
+ - `name()` *(since 0.48.0)*: returns the name of the dependency that was
    searched. Returns `internal` for dependencies created with
    `declare_dependency()`.
 
- - `get_pkgconfig_variable(varname)` *(Added 0.36.0)* will get the
+ - `get_pkgconfig_variable(varname)` *(since 0.36.0)*: gets the
    pkg-config variable specified, or, if invoked on a non pkg-config
-   dependency, error out. *(Added 0.44.0)* You can also redefine a
+   dependency, error out. *(since 0.44.0)* You can also redefine a
    variable by passing a list to the `define_variable` parameter
    that can affect the retrieved variable: `['prefix', '/'])`.
-   *(Added 0.45.0)* A warning is issued if the variable is not defined,
+   *(since 0.45.0)* A warning is issued if the variable is not defined,
    unless a `default` parameter is specified.
 
- - `get_configtool_variable(varname)` *(Added 0.44.0)* will get the
+ - `get_configtool_variable(varname)` *(since 0.44.0)*: gets the
    command line argument from the config tool (with `--` prepended), or,
    if invoked on a non config-tool dependency, error out.
 
- - `type_name()` which returns a string describing the type of the
+ - `type_name()`: returns a string describing the type of the
    dependency, the most common values are `internal` for deps created
    with `declare_dependency()` and `pkgconfig` for system dependencies
    obtained with Pkg-config.
 
- - `version()` is the version number as a string, for example `1.2.8`.
+ - `version()`: the version number as a string, for example `1.2.8`.
    `unknown` if the dependency provider doesn't support determining the
    version.
 
- - `include_type()` returns whether the value set by the `include_type` kwarg
+ - `include_type()`: returns whether the value set by the `include_type` kwarg
 
- - `as_system(value)` returns a copy of the dependency object, which has changed
+ - `as_system(value)`: returns a copy of the dependency object, which has changed
    the value of `include_type` to `value`. The `value` argument is optional and
    defaults to `'preserve'`.
 
  - `partial_dependency(compile_args : false, link_args : false, links
-   : false, includes : false, source : false)` *(Added 0.46.0)* returns
+   : false, includes : false, sources : false)` *(since 0.46.0)*: returns
    a new dependency object with the same name, version, found status,
    type name, and methods as the object that called it. This new
    object will only inherit other attributes from its parent as
    controlled by keyword arguments.
 
    If the parent has any dependencies, those will be applied to the new
-   partial dependency with the same rules. So , given:
+   partial dependency with the same rules. So, given:
 
    ```meson
    dep1 = declare_dependency(compile_args : '-Werror=foo', link_with : 'libfoo')
@@ -2430,14 +2451,14 @@ an external dependency with the following methods:
 
  - `get_variable(cmake : str, pkgconfig : str, configtool : str,
    internal: str, default_value : str, pkgconfig_define : [str, str])`
-   *(Added in 0.51.0)* A generic variable getter method, which replaces the
+   *(since 0.51.0)*: a generic variable getter method, which replaces the
    get_*type*_variable methods. This allows one to get the variable
    from a dependency without knowing specifically how that dependency
    was found. If default_value is set and the value cannot be gotten
    from the object then default_value is returned, if it is not set
    then an error is raised.
 
-   *New in 0.54.0, the `internal` keyword*
+   *(since 0.54.0)* added `internal` keyword.
 
 ### `disabler` object
 
@@ -2447,7 +2468,7 @@ statement (function call, logical op, etc) they will cause the
 statement evaluation to immediately short circuit to return a disabler
 object. A disabler object has one method:
 
-  - `found()`, always returns `false`
+- `found()`: always returns `false`.
 
 ### `external program` object
 
@@ -2455,11 +2476,16 @@ This object is returned by [`find_program()`](#find_program) and
 contains an external (i.e. not built as part of this project) program
 and has the following methods:
 
-- `found()` which returns whether the executable was found
+- `found()`: returns whether the executable was found.
 
-- `path()` which returns a string pointing to the script or executable
+- `path()`: *(since 0.55.0)* **(deprecated)** use `full_path()` instead.
+  Returns a string pointing to the script or executable
   **NOTE:** You should not need to use this method. Passing the object
-  itself should work in all cases. For example: `run_command(obj, arg1, arg2)`
+  itself should work in all cases. For example: `run_command(obj, arg1, arg2)`.
+
+- `full_path()` (*since 0.55.0*): which returns a string pointing to the script or
+  executable **NOTE:** You should not need to use this method. Passing the object
+  itself should work in all cases. For example: `run_command(obj, arg1, arg2)`.
 
 ### `environment` object
 
@@ -2468,7 +2494,7 @@ detailed information about how environment variables should be set
 during tests. It should be passed as the `env` keyword argument to
 tests and other functions. It has the following methods.
 
-- `append(varname, value1, value2, ...)` appends the given values to
+- `append(varname, value1, value2, ...)`: appends the given values to
   the old value of the environment variable, e.g.  `env.append('FOO',
   'BAR', 'BAZ', separator : ';')` produces `BOB;BAR;BAZ` if `FOO` had
   the value `BOB` and plain `BAR;BAZ` if the value was not defined. If
@@ -2476,10 +2502,10 @@ tests and other functions. It has the following methods.
   separator for the host operating system will be used, i.e. ';' for
   Windows and ':' for UNIX/POSIX systems.
 
-- `prepend(varname, value1, value2, ...)` is the same as `append`
-  except that it writes to the beginning of the variable
+- `prepend(varname, value1, value2, ...)`: same as `append`
+  except that it writes to the beginning of the variable.
 
-- `set(varname, value1, value2)` sets the environment variable
+- `set(varname, value1, value2)`: sets the environment variable
   specified in the first argument to the values in the second argument
   joined by the separator, e.g.  `env.set('FOO', 'BAR'),` sets envvar
   `FOO` to value `BAR`. See `append()` above for how separators work.
@@ -2493,27 +2519,27 @@ This object is returned by [`find_library()`](#find_library) and
 contains an external (i.e. not built as part of this project)
 library. This object has the following methods:
 
- - `found()` which returns whether the library was found.
+- `found()`: returns whether the library was found.
 
- - `type_name()` *(added 0.48.0)* which returns a string describing
-   the type of the dependency, which will be `library` in this case.
+- `type_name()` *(since 0.48.0)*: returns a string describing
+  the type of the dependency, which will be `library` in this case.
 
- - `partial_dependency(compile_args : false, link_args : false, links
-   : false, includes : false, source : false)` *(Added 0.46.0)* returns
-   a new dependency object with the same name, version, found status,
-   type name, and methods as the object that called it. This new
-   object will only inherit other attributes from its parent as
-   controlled by keyword arguments.
+- `partial_dependency(compile_args : false, link_args : false, links
+  : false, includes : false, source : false)` *(since 0.46.0)*: returns
+  a new dependency object with the same name, version, found status,
+  type name, and methods as the object that called it. This new
+  object will only inherit other attributes from its parent as
+  controlled by keyword arguments.
 
 ### Feature option object
 
-The following methods are defined for all [`feature` options](Build-options.md#features):
+*(since 0.47.0)*
 
-- `enabled()` returns whether the feature was set to `'enabled'`
-- `disabled()` returns whether the feature was set to `'disabled'`
-- `auto()` returns whether the feature was set to `'auto'`
+The following methods are defined for all [`feature` options](Build-options.md#features):
 
-Feature options are available since 0.47.0.
+- `enabled()`: returns whether the feature was set to `'enabled'`
+- `disabled()`: returns whether the feature was set to `'disabled'`
+- `auto()`: returns whether the feature was set to `'auto'`
 
 ### `generator` object
 
@@ -2521,7 +2547,7 @@ This object is returned by [`generator()`](#generator) and contains a
 generator that is used to transform files from one type to another by
 an executable (e.g. `idl` files into source code and headers).
 
-* `process(list_of_files, ...)` takes a list of files, causes them to
+- `process(list_of_files, ...)`: takes a list of files, causes them to
   be processed and returns an object containing the result which can
   then, for example, be passed into a build target definition. The
   keyword argument `extra_args`, if specified, will be used to replace
@@ -2539,10 +2565,10 @@ an executable (e.g. `idl` files into source code and headers).
 This object is returned by [`subproject()`](#subproject) and is an
 opaque object representing it.
 
-- `found()` *(added 0.48.0)* which returns whether the subproject was
+- `found()` *(since 0.48.0)*: returns whether the subproject was
   successfully setup
 
-- `get_variable(name, fallback)` fetches the specified variable from
+- `get_variable(name, fallback)`: fetches the specified variable from
   inside the subproject. This is useful to, for instance, get a
   [declared dependency](#declare_dependency) from the
   [subproject](Subprojects.md).
@@ -2557,9 +2583,9 @@ This object encapsulates the result of trying to compile and run a
 sample piece of code with [`compiler.run()`](#compiler-object) or
 [`run_command()`](#run_command). It has the following methods:
 
-- `compiled()` if true, the compilation succeeded, if false it did not
+- `compiled()`: if true, the compilation succeeded, if false it did not
   and the other methods return unspecified data. This is only available
   for `compiler.run()` results.
-- `returncode()` the return code of executing the compiled binary
-- `stderr()` the standard error produced when the command was run
-- `stdout()` the standard out produced when the command was run
+- `returncode()`: the return code of executing the compiled binary
+- `stderr()`: the standard error produced when the command was run
+- `stdout()`: the standard out produced when the command was run
diff --git a/docs/markdown/Reference-tables.md b/docs/markdown/Reference-tables.md
index dfae339..3be129f 100644
--- a/docs/markdown/Reference-tables.md
+++ b/docs/markdown/Reference-tables.md
@@ -81,14 +81,17 @@ set in the cross file.
 | alpha               | DEC Alpha processor      |
 | arc                 | 32 bit ARC processor     |
 | arm                 | 32 bit ARM processor     |
-| e2k                 | MCST Elbrus processor    |
+| avr                 | Atmel AVR processor      |
 | c2000               | 32 bit C2000 processor   |
+| dspic               | 16 bit Microchip dsPIC   |
+| e2k                 | MCST Elbrus processor    |
 | ia64                | Itanium processor        |
 | m68k                | Motorola 68000 processor |
 | microblaze          | MicroBlaze processor     |
 | mips                | 32 bit MIPS processor    |
 | mips64              | 64 bit MIPS processor    |
 | parisc              | HP PA-RISC processor     |
+| pic24               | 16 bit Microchip PIC24   |
 | ppc                 | 32 bit PPC processors    |
 | ppc64               | 64 bit PPC processors    |
 | riscv32             | 32 bit RISC-V Open ISA   |
@@ -97,12 +100,11 @@ set in the cross file.
 | rx                  | Renesas RX 32 bit MCU    |
 | s390                | IBM zSystem s390         |
 | s390x               | IBM zSystem s390x        |
+| sh4                 | SuperH SH-4              |
 | sparc               | 32 bit SPARC             |
 | sparc64             | SPARC v9 processor       |
 | wasm32              | 32 bit Webassembly       |
 | wasm64              | 64 bit Webassembly       |
-| pic24               | 16 bit Microchip PIC24   |
-| dspic               | 16 bit Microchip dsPIC   |
 | x86                 | 32 bit x86 processor     |
 | x86_64              | 64 bit x86 processor     |
 
@@ -120,6 +122,7 @@ These are provided by the `.system()` method call.
 
 | Value               | Comment                         |
 | -----               | -------                         |
+| android             | By convention only, subject to change |
 | cygwin              | The Cygwin environment for Windows |
 | darwin              | Either OSX or iOS |
 | dragonfly           | DragonFly BSD |
@@ -153,6 +156,10 @@ These are the parameter names for passing language specific arguments to your bu
 | Rust          | rust_args     | rust_link_args    |
 | Vala          | vala_args     | vala_link_args    |
 
+All these `<lang>_*` options are specified per machine. See in [specifying
+options per machine](Builtin-options.md#Specifying-options-per-machine) for on
+how to do this in cross builds.
+
 ## Compiler and linker flag environment variables
 
 These environment variables will be used to modify the compiler and
@@ -175,6 +182,10 @@ instead.
 | RUSTFLAGS | Flags for the Rust compiler              |
 | LDFLAGS   | The linker flags, used for all languages |
 
+N.B. these settings are specified per machine, and so the environment varibles
+actually come in pairs. See the [environment variables per
+machine](#Environment-variables-per-machine) section for details.
+
 ## Function Attributes
 
 These are the parameters names that are supported using
@@ -187,49 +198,50 @@ These values are supported using the GCC style `__attribute__` annotations,
 which are supported by GCC, Clang, and other compilers.
 
 
-| Name                 |
-|----------------------|
-| alias                |
-| aligned              |
-| alloc_size           |
-| always_inline        |
-| artificial           |
-| cold                 |
-| const                |
-| constructor          |
-| constructor_priority |
-| deprecated           |
-| destructor           |
-| error                |
-| externally_visible   |
-| fallthrough          |
-| flatten              |
-| format               |
-| format_arg           |
-| gnu_inline           |
-| hot                  |
-| ifunc                |
-| malloc               |
-| noclone              |
-| noinline             |
-| nonnull              |
-| noreturn             |
-| nothrow              |
-| optimize             |
-| packed               |
-| pure                 |
-| returns_nonnull      |
-| unused               |
-| used                 |
-| visibility*          |
-| visibility:default†  |
-| visibility:hidden†   |
-| visibility:internal† |
-| visibility:protected†|
-| warning              |
-| warn_unused_result   |
-| weak                 |
-| weakreaf             |
+| Name                     |
+|--------------------------|
+| alias                    |
+| aligned                  |
+| alloc_size               |
+| always_inline            |
+| artificial               |
+| cold                     |
+| const                    |
+| constructor              |
+| constructor_priority     |
+| deprecated               |
+| destructor               |
+| error                    |
+| externally_visible       |
+| fallthrough              |
+| flatten                  |
+| format                   |
+| format_arg               |
+| force_align_arg_pointer³ |
+| gnu_inline               |
+| hot                      |
+| ifunc                    |
+| malloc                   |
+| noclone                  |
+| noinline                 |
+| nonnull                  |
+| noreturn                 |
+| nothrow                  |
+| optimize                 |
+| packed                   |
+| pure                     |
+| returns_nonnull          |
+| unused                   |
+| used                     |
+| visibility*              |
+| visibility:default†      |
+| visibility:hidden†       |
+| visibility:internal†     |
+| visibility:protected†    |
+| warning                  |
+| warn_unused_result       |
+| weak                     |
+| weakreaf                 |
 
 \* *Changed in 0.52.0* the "visibility" target no longer includes
 "protected", which is not present in Apple's clang.
@@ -237,6 +249,8 @@ which are supported by GCC, Clang, and other compilers.
 † *New in 0.52.0* These split visibility attributes are preferred to the plain
 "visibility" as they provide narrower checks.
 
+³ *New in 0.55.0*
+
 ### MSVC __declspec
 
 These values are supported using the MSVC style `__declspec` annotation,
@@ -265,6 +279,10 @@ These are the values that can be passed to `dependency` function's
 
 ## Compiler and Linker selection variables
 
+N.B. these settings are specified per machine, and so the environment varibles
+actually come in pairs. See the [environment variables per
+machine](#Environment-variables-per-machine) section for details.
+
 | Language      | Compiler | Linker    | Note                                        |
 |---------------|----------|-----------|---------------------------------------------|
 | C             | CC       | CC_LD     |                                             |
@@ -278,5 +296,28 @@ These are the values that can be passed to `dependency` function's
 | C#            | CSC      | CSC       | The linker is the compiler                  |
 
 *The old environment variales are still supported, but are deprecated and will
-be removed in a future version of meson.
+be removed in a future version of meson.*
+
+## Environment variables per machine
+
+Since *0.54.0*, Following Autotool and other legacy build systems, environment
+variables that affect machine-specific settings come in pairs: for every bare
+environment variable `FOO`, there is a suffixed `FOO_FOR_BUILD`, where `FOO`
+just affects the host machine configuration, while `FOO_FOR_BUILD` just affects
+the build machine configuration. For example:
+
+ - `PKG_CONFIG_PATH_FOR_BUILD` controls the paths pkg-config will search for
+   just `native: true` dependencies (build machine).
+
+ - `PKG_CONFIG_PATH` controls the paths pkg-config will search for just
+   `native: false` dependencies (host machine).
+
+This mirrors the `build.` prefix used for (built-in) meson options, which has
+the same meaning.
+
+This is useful for cross builds. In the native builds, build = host, and the
+unsuffixed environment variables alone will suffice.
 
+Prior to *0.54.0*, there was no `_FOR_BUILD`-suffixed variables, and most
+environment variables only effected native machine configurations, though this
+wasn't consistent (e.g. `PKG_CONFIG_PATH` still affected cross builds).
diff --git a/docs/markdown/Release-notes-for-0.54.0.md b/docs/markdown/Release-notes-for-0.54.0.md
index 2c8880c..2f215de 100644
--- a/docs/markdown/Release-notes-for-0.54.0.md
+++ b/docs/markdown/Release-notes-for-0.54.0.md
@@ -14,7 +14,7 @@ If it set to 0 then the PTHREAD_POOL_SIZE option will not be passed.
 
 ## Introduce dataonly for the pkgconfig module
 This allows users to disable writing out the inbuilt variables to
-the pkg-config file as they might actualy not be required.
+the pkg-config file as they might actually not be required.
 
 One reason to have this is for architecture-independent pkg-config
 files in projects which also have architecture-dependent outputs.
@@ -359,3 +359,8 @@ target that has eight source files, Meson will generate two unity
 files each of which includes four source files. The old behaviour can
 be replicated by setting `unity_size` to a large value, such as 10000.
 
+## Verbose mode for `meson compile`
+
+The new option `--verbose` has been added to `meson compile` that will enable
+more verbose compilation logs. Note that for VS backend it means that logs will
+be less verbose by default (without `--verbose` option).
diff --git a/docs/markdown/Release-notes-for-0.55.0.md b/docs/markdown/Release-notes-for-0.55.0.md
new file mode 100644
index 0000000..534c452
--- /dev/null
+++ b/docs/markdown/Release-notes-for-0.55.0.md
@@ -0,0 +1,307 @@
+---
+title: Release 0.55.0
+short-description: Release notes for 0.55.0
+...
+
+# New features
+
+## rpath removal now more careful
+
+On Linux-like systems, meson adds rpath entries to allow running apps
+in the build tree, and then removes those build-time-only
+rpath entries when installing.  Rpath entries may also come
+in via LDFLAGS and via .pc files.  Meson used to remove those
+latter rpath entries by accident, but is now more careful.
+
+## Added ability to specify targets in `meson compile`
+
+It's now possible to specify targets in `meson compile`, which will result in building only the requested targets.
+
+Usage: `meson compile [TARGET [TARGET...]]`
+`TARGET` has the following syntax: `[PATH/]NAME[:TYPE]`.
+`NAME`: name of the target from `meson.build` (e.g. `foo` from `executable('foo', ...)`).
+`PATH`: path to the target relative to the root `meson.build` file. Note: relative path for a target specified in the root `meson.build` is `./`.
+`TYPE`: type of the target (e.g. `shared_library`, `executable` and etc)
+
+`PATH` and/or `TYPE` can be ommited if the resulting `TARGET` can be used to uniquely identify the target in `meson.build`.
+
+For example targets from the following code:
+```meson
+shared_library('foo', ...)
+static_library('foo', ...)
+executable('bar', ...)
+```
+can be invoked with `meson compile foo:shared_library foo:static_library bar`.
+
+## Test protocol for gtest
+
+Due to the popularity of Gtest (google test) among C and C++ developers meson
+now supports a special protocol for gtest. With this protocol meson injects
+arguments to gtests to output JUnit, reads that JUnit, and adds the output to
+the JUnit it generates.
+
+## meson.add_*_script methods accept new types
+
+All three (`add_install_script`, `add_dist_script`, and
+`add_postconf_script`) now accept ExternalPrograms (as returned by
+`find_program`), Files, and the output of `configure_file`. The dist and
+postconf methods cannot accept other types because of when they are run.
+While dist could, in theory, take other dependencies, it would require more
+extensive changes, particularly to the backend.
+
+```meson
+meson.add_install_script(find_program('foo'), files('bar'))
+meson.add_dist_script(find_program('foo'), files('bar'))
+meson.add_postconf_script(find_program('foo'), files('bar'))
+```
+
+The install script variant is also able to accept custom_targets,
+custom_target indexes, and build targets (executables, libraries), and can
+use built executables a the script to run
+
+```meson
+installer = executable('installer', ...)
+meson.add_install_script(installer, ...)
+meson.add_install_script('foo.py', installer)
+```
+
+## Machine file constants
+
+Native and cross files now support string and list concatenation using the `+`
+operator, and joining paths using the `/` operator.
+Entries defined in the `[constants]` section can be used in any other section.
+An entry defined in any other section can be used only within that same section and only
+after it has been defined.
+
+```ini
+[constants]
+toolchain = '/toolchain'
+common_flags = ['--sysroot=' + toolchain + '/sysroot']
+
+[properties]
+c_args = common_flags + ['-DSOMETHING']
+cpp_args = c_args + ['-DSOMETHING_ELSE']
+
+[binaries]
+c = toolchain + '/gcc'
+```
+
+## Configure CMake subprojects with meson.subproject_options
+
+Meson now supports passing configuration options to CMake and overriding
+certain build details extracted from the CMake subproject.
+
+The new CMake configuration options object is very similar to the
+[configuration data object](Reference-manual.md#configuration-data-object) object
+returned by [`configuration_data`](Reference-manual.md#configuration_data). It
+is generated by the `subproject_options` function
+
+All configuration options have to be set *before* the subproject is configured
+and must be passed to the `subproject` method via the `options` key. Altering
+the configuration object won't have any effect on previous `cmake.subproject`
+calls.
+
+**Note:** The `cmake_options` kwarg for the `subproject` function is now
+deprecated since it is replaced by the new `options` system.
+
+## find_program: Fixes when the program has been overridden by executable
+
+When a program has been overridden by an executable, the returned object of
+find_program() had some issues:
+
+```meson
+# In a subproject:
+exe = executable('foo', ...)
+meson.override_find_program('foo', exe)
+
+# In main project:
+# The version check was crashing meson.
+prog = find_program('foo', version : '>=1.0')
+
+# This was crashing meson.
+message(prog.path())
+
+# New method to be consistent with built objects.
+message(prog.full_path())
+```
+
+## Response files enabled on Linux, reined in on Windows
+
+Meson used to always use response files on Windows,
+but never on Linux.
+
+It now strikes a happier balance, using them on both platforms,
+but only when needed to avoid command line length limits.
+
+## `unstable-kconfig` module renamed to `unstable-keyval`
+
+The `unstable-kconfig` module is now renamed to `unstable-keyval`.
+We expect this module to become stable once it has some usage experience,
+specifically in the next or the following release
+
+
+## Fatal warnings in `gnome.generate_gir()`
+
+`gnome.generate_gir()` now has `fatal_warnings` keyword argument to abort when
+a warning is produced. This is useful for example in CI environment where it's
+important to catch potential issues.
+
+## b_ndebug support for D language compilers
+
+D Language compilers will now set -release/--release/-frelease (depending on
+the compiler) when the b_ndebug flag is set.
+
+## Meson test now produces JUnit xml from results
+
+Meson will now generate a JUnit compatible XML file from test results. it
+will be in the meson-logs directory and is called testlog.junit.xml.
+
+## Config tool based dependencies no longer search PATH for cross compiling
+
+Before 0.55.0 config tool based dependencies (llvm-config, cups-config, etc),
+would search system $PATH if they weren't defined in the cross file. This has
+been a source of bugs and has been deprecated. It is now removed, config tool
+binaries must be specified in the cross file now or the dependency will not
+be found.
+
+## Rename has_exe_wrapper -> can_run_host_binaries
+
+The old name was confusing as it didn't really match the behavior of the
+function. The old name remains as an alias (the behavior hasn't changed), but
+is now deprecated.
+
+## String concatenation in meson_options.txt
+
+It is now possible to use string concatenation (with the `+` opperator) in the
+meson_options.txt file. This allows splitting long option descriptions.
+
+```meson
+option(
+  'testoption',
+  type : 'string',
+  value : 'optval',
+  description : 'An option with a very long description' +
+                'that does something in a specific context'
+)
+```
+
+## Wrap fallback URL
+
+Wrap files can now define `source_fallback_url` and `patch_fallback_url` to be
+used in case the main server is temporaly down.
+
+## Clang coverage support
+
+llvm-cov is now used to generate coverage information when clang is used as
+the compiler.
+
+## Local wrap source and patch files
+
+It is now possible to use the `patch_filename` and `source_filename` value in a
+`.wrap` file without `*_url` to specify a local source / patch file. All local
+files must be located in the `subprojects/packagefiles` directory. The `*_hash`
+entries are optional with this setup.
+
+## Local wrap patch directory
+
+Wrap files can now specify `patch_directory` instead of `patch_filename` in the
+case overlay files are local. Every files in that directory, and subdirectories,
+will be copied to the subproject directory. This can be used for example to add
+`meson.build` files to a project not using Meson build system upstream.
+The patch directory must be placed in `subprojects/packagefiles` directory.
+
+## Patch on all wrap types
+
+`patch_*` keys are not limited to `wrap-file` any more, they can be specified for
+all wrap types.
+
+## link_language argument added to all targets
+
+Previously the `link_language` argument was only supposed to be allowed in
+executables, because the linker used needs to be the linker for the language
+that implements the main function. Unfortunately it didn't work in that case,
+and, even worse, if it had been implemented properly it would have worked for
+*all* targets. In 0.55.0 this restriction has been removed, and the bug fixed.
+It now is valid for `executable` and all derivative of `library`.
+
+## meson dist --no-tests
+
+`meson dist` has a new option `--no-tests` to skip build and tests of generated
+packages. It can be used to not waste time for example when done in CI that
+already does its own testing.
+
+## Force fallback for
+
+A newly-added `--force-fallback-for` command line option can now be used to
+force fallback for specific subprojects.
+
+Example:
+
+```
+meson build --force-fallback-for=foo,bar
+```
+
+## Implicit dependency fallback
+
+`dependency('foo')` now automatically fallback if the dependency is not found on
+the system but a subproject wrap file or directory exists with the same name.
+
+That means that simply adding `subprojects/foo.wrap` is enough to add fallback
+to any `dependency('foo')` call. It is however requires that the subproject call
+`meson.override_dependency('foo', foo_dep)` to specify which dependency object
+should be used for `foo`.
+
+## Wrap file `provide` section
+
+Wrap files can define the dependencies it provides in the `[provide]` section.
+When `foo.wrap` provides the dependency `foo-1.0` any call do `dependency('foo-1.0')`
+will automatically fallback to that subproject even if no `fallback` keyword
+argument is given. See [Wrap documentation](Wrap-dependency-system-manual.md#provide_section).
+
+## `find_program()` fallback
+
+When a program cannot be found on the system but a wrap file has its name in the
+`[provide]` section, that subproject will be used as fallback.
+
+## Test scripts are given the exe wrapper if needed
+
+Meson will now set the `MESON_EXE_WRAPPER` as the properly wrapped and joined
+representation. For Unix-like OSes this means python's shelx.join, on Windows
+an implementation that attempts to properly quote windows argument is used.
+This allow wrapper scripts to run test binaries, instead of just skipping.
+
+for example, if the wrapper is `['emulator', '--script']`, it will be passed
+as `MESON_EXE_WRAPPER="emulator --script"`.
+
+## Added ability to specify backend arguments in `meson compile`
+
+It's now possible to specify backend specific arguments in `meson compile`.
+
+Usage: `meson compile [--vs-args=args] [--ninja-args=args]`
+
+```
+  --ninja-args NINJA_ARGS    Arguments to pass to `ninja` (applied only on `ninja` backend).
+  --vs-args VS_ARGS          Arguments to pass to `msbuild` (applied only on `vs` backend).
+```
+
+These arguments use the following syntax:
+
+If you only pass a single string, then it is considered to have all values separated by commas. Thus invoking the following command:
+
+```
+$ meson compile --ninja-args=-n,-d,explain
+```
+
+would add `-n`, `-d` and `explain` arguments to ninja invocation.
+
+If you need to have commas or spaces in your string values, then you need to pass the value with proper shell quoting like this:
+
+```
+$ meson compile "--ninja-args=['a,b', 'c d']"
+```
+
+## Introspection API changes
+
+dumping the AST (--ast): **new in 0.55.0**
+- prints the AST of a meson.build as JSON
+
diff --git a/docs/markdown/Run-targets.md b/docs/markdown/Run-targets.md
index 38129a6..b584bf7 100644
--- a/docs/markdown/Run-targets.md
+++ b/docs/markdown/Run-targets.md
@@ -29,7 +29,7 @@ run_target('inspector',
 Run targets are not run by default. To run it run the following command.
 
 ```console
-$ ninja inspector
+$ meson compile inspector
 ```
 
 All additional entries in `run_target`'s `command` array are passed unchanged to the inspector script, so you can do things like this:
diff --git a/docs/markdown/Running-Meson.md b/docs/markdown/Running-Meson.md
index 910513c..326ecb9 100644
--- a/docs/markdown/Running-Meson.md
+++ b/docs/markdown/Running-Meson.md
@@ -9,13 +9,12 @@ from the source tree with the command `/path/to/source/meson.py`. Meson may
 also be installed in which case the command is simply `meson`. In this manual
 we only use the latter format for simplicity.
 
-Additionally, the invocation can pass options to meson. The list of options is
-documented [here](Builtin-options.md).
-
 At the time of writing only a command line version of Meson is available. This
 means that Meson must be invoked using the terminal. If you wish to use the
 MSVC compiler, you need to run Meson under "Visual Studio command prompt".
 
+All available meson commands are listed on the [commands reference page](Commands.md).
+
 ## Configuring the build directory
 
 Let us assume that we have a source tree that has a Meson build system. This
@@ -41,6 +40,9 @@ build backend in the build directory. By default Meson generates a *debug
 build*, which turns on basic warnings and debug information and disables
 compiler optimizations.
 
+Additionally, the invocation can pass options to meson. The list of options is
+documented [here](Builtin-options.md).
+
 You can specify a different type of build with the `--buildtype` command line
 argument. It can have one of the following values.
 
@@ -83,7 +85,7 @@ during configuration time. As an example, here is how you would use Meson to
 generate a Visual studio solution.
 
 ```sh
-meson setup <build dir> --backend=vs2010
+meson setup <build dir> --backend=vs
 ```
 
 You can then open the generated solution with Visual Studio and compile it in
@@ -105,9 +107,18 @@ linker arguments needed.
 
 ## Building from the source
 
-If you are not using an IDE, Meson uses the [Ninja build
-system](https://ninja-build.org/) to actually build the code. To start the
-build, simply type the following command.
+To start the build, simply type the following command.
+
+```sh
+meson compile -C builddir
+```
+
+See [`meson compile` description](Commands.md#compile) for more info.
+
+### Building directly with ninja
+
+By default Meson uses the [Ninja build system](https://ninja-build.org/) to 
+actually build the code. To start the build, simply type the following command.
 
 ```sh
 ninja -C builddir
@@ -133,20 +144,29 @@ Meson provides native support for running tests. The command to do that is
 simple.
 
 ```sh
-ninja -C builddir test
+meson test -C builddir
 ```
 
+See [`meson test` description](Commands.md#test) for more info.
+
 Meson does not force the use of any particular testing framework. You are free
 to use GTest, Boost Test, Check or even custom executables.
 
+Note: it can be also invoked directly with ninja with the following command:
+```sh
+ninja -C builddir test
+```
+
 ## Installing
 
 Installing the built software is just as simple.
 
 ```sh
-ninja -C builddir install
+meson install -C builddir
 ```
 
+See [`meson install` description](Commands.md#install) for more info.
+
 Note that Meson will only install build targets explicitly tagged as
 installable, as detailed in the [installing targets
 documentation](Installing.md).
@@ -157,7 +177,12 @@ Meson also supports the `DESTDIR` variable used in e.g. building packages. It
 is used like this:
 
 ```sh
-DESTDIR=/path/to/staging ninja -C builddir install
+DESTDIR=/path/to/staging meson install -C builddir
+```
+
+Note: it can be also invoked directly with ninja with the following command:
+```sh
+ninja -C builddir install
 ```
 
 ## Command line help
diff --git a/docs/markdown/Style-guide.md b/docs/markdown/Style-guide.md
index ee2ecfe..960e60c 100644
--- a/docs/markdown/Style-guide.md
+++ b/docs/markdown/Style-guide.md
@@ -11,6 +11,12 @@ Meson build files.
 
 Always spaces.
 
+## Naming Variable
+
+The most consistent naming convention is the snake case. Let say you would
+like to refer to your executable so something like `my_exe` would work or
+just `exe`.
+
 ## Naming options
 
 There are two ways of naming project options. As an example for
diff --git a/docs/markdown/Subprojects.md b/docs/markdown/Subprojects.md
index 8232da9..02a83e6 100644
--- a/docs/markdown/Subprojects.md
+++ b/docs/markdown/Subprojects.md
@@ -212,6 +212,9 @@ the following command-line options:
     calls, and those are meant to be used for sources that cannot be
     provided by the system, such as copylibs.
 
+    This option may be overriden by `--force-fallback-for` for specific
+    dependencies.
+
 * **--wrap-mode=forcefallback**
 
     Meson will not look at the system for any dependencies which have
@@ -220,6 +223,41 @@ the following command-line options:
     want to specifically build against the library sources provided by
     your subprojects.
 
+* **--force-fallback-for=list,of,dependencies**
+
+    Meson will not look at the system for any dependencies listed there,
+    provided a fallback was supplied when the dependency was declared.
+
+    This option takes precedence over `--wrap-mode=nofallback`, and when
+    used in combination with `--wrap-mode=nodownload` will only work
+    if the dependency has already been downloaded.
+
+    This is useful when your project has many fallback dependencies,
+    but you only want to build against the library sources for a few
+    of them.
+
+    **Warning**: This could lead to mixing system and subproject version of the
+    same library in the same process. Take this case as example:
+    - Libraries `glib-2.0` and `gstreamer-1.0` are installed on your system.
+    - `gstreamer-1.0` depends on `glib-2.0`, pkg-config file `gstreamer-1.0.pc`
+      has `Requires: glib-2.0`.
+    - In your application build definition you do:
+      ```meson
+      executable('app', ...,
+        dependencies: [
+          dependency('glib-2.0', fallback: 'glib'),
+          dependency('gstreamer-1.0', fallback: 'gstreamer')],
+      )
+      ```
+    - You configure with `--force-fallback-for=glib`.
+    This result in linking to two different versions of library `glib-2.0`
+    because `dependency('glib-2.0', fallback: 'glib')` will return the
+    subproject dependency, but `dependency('gstreamer-1.0', fallback: 'gstreamer')`
+    will not fallback and return the system dependency, including `glib-2.0`
+    library. To avoid that situation, every dependency that itself depend on
+    `glib-2.0` must also be forced to fallback, in this case with
+    `--force-fallback-for=glib,gsteamer`.
+
 ## Download subprojects
 
 *Since 0.49.0*
diff --git a/docs/markdown/Syntax.md b/docs/markdown/Syntax.md
index cf0516c..bbe3dbb 100644
--- a/docs/markdown/Syntax.md
+++ b/docs/markdown/Syntax.md
@@ -16,12 +16,12 @@ statements* and *includes*.
 Usually one Meson statement takes just one line. There is no way to
 have multiple statements on one line as in e.g. *C*. Function and
 method calls' argument lists can be split over multiple lines. Meson
-will autodetect this case and do the right thing. In other cases you
-can get multi-line statements by ending the line with a `\`. Apart
-from line ending whitespace has no syntactic meaning.
+will autodetect this case and do the right thing.
 
-Variables
---
+In other cases, *(added 0.50)* you can get multi-line statements by ending the
+line with a `\`.  Apart from line ending whitespace has no syntactic meaning.
+
+## Variables
 
 Variables in Meson work just like in other high level programming
 languages. A variable can contain a value of any type, such as an
@@ -46,8 +46,7 @@ var2 += [4]
 # var1 is still [1, 2, 3]
 ```
 
-Numbers
---
+## Numbers
 
 Meson supports only integer numbers. They are declared simply by
 writing them out. Basic arithmetic operations are supported.
@@ -85,8 +84,7 @@ int_var = 42
 string_var = int_var.to_string()
 ```
 
-Booleans
---
+## Booleans
 
 A boolean is either `true` or `false`.
 
@@ -94,8 +92,7 @@ A boolean is either `true` or `false`.
 truth = true
 ```
 
-Strings
---
+## Strings
 
 Strings in Meson are declared with single quotes. To enter a literal
 single quote do it like this:
@@ -126,7 +123,7 @@ As in python and C, up to three octal digits are accepted in `\ooo`.
 Unrecognized escape sequences are left in the string unchanged, i.e., the
 backslash is left in the string.
 
-#### String concatenation
+### String concatenation
 
 Strings can be concatenated to form a new string using the `+` symbol.
 
@@ -136,7 +133,25 @@ str2 = 'xyz'
 combined = str1 + '_' + str2 # combined is now abc_xyz
 ```
 
-#### Strings running over multiple lines
+### String path building
+
+*(Added 0.49)*
+
+You can concatenate any two strings using `/` as an operator to build paths.
+This will always use `/` as the path separator on all platforms.
+
+```meson
+joined = '/usr/share' / 'projectname'    # => /usr/share/projectname
+joined = '/usr/local' / '/etc/name'      # => /etc/name
+
+joined = 'C:\\foo\\bar' / 'builddir'     # => C:/foo/bar/builddir
+joined = 'C:\\foo\\bar' / 'D:\\builddir' # => D:/builddir
+```
+
+Note that this is equivalent to using [`join_paths()`](Reference-manual.md#join_paths),
+which was obsoleted by this operator.
+
+### Strings running over multiple lines
 
 Strings running over multiple lines can be declared with three single
 quotes, like this:
@@ -152,7 +167,7 @@ These are raw strings that do not support the escape sequences listed
 above.  These strings can also be combined with the string formatting
 functionality described below.
 
-#### String formatting
+### String formatting
 
 Strings can be built using the string formatting functionality.
 
@@ -165,12 +180,12 @@ res = template.format('text', 1, true)
 As can be seen, the formatting works by replacing placeholders of type
 `@number@` with the corresponding argument.
 
-#### String methods
+### String methods
 
 Strings also support a number of other methods that return transformed
 copies.
 
-**.strip()**
+#### .strip()
 
 ```meson
 # Similar to the Python str.strip(). Removes leading/ending spaces and newlines
@@ -179,7 +194,7 @@ stripped_define = define.strip()
 # 'stripped_define' now has the value '-Dsomedefine'
 ```
 
-**.to_upper()**, **.to_lower()**
+#### .to_upper(), .to_lower()
 
 ```meson
 target = 'x86_FreeBSD'
@@ -187,7 +202,7 @@ upper = target.to_upper() # t now has the value 'X86_FREEBSD'
 lower = target.to_lower() # t now has the value 'x86_freebsd'
 ```
 
-**.to_int()**
+#### .to_int()
 
 ```meson
 version = '1'
@@ -195,7 +210,7 @@ version = '1'
 ver_int = version.to_int()
 ```
 
-**.contains()**, **.startswith()**, **.endswith()**
+#### .contains(), .startswith(), .endswith()
 
 ```meson
 target = 'x86_FreeBSD'
@@ -205,7 +220,27 @@ is_x86 = target.startswith('x86') # boolean value 'true'
 is_bsd = target.to_lower().endswith('bsd') # boolean value 'true'
 ```
 
-**.split()**, **.join()**
+#### .substring()
+
+Since 0.56.0, you can extract a substring from a string.
+
+```meson
+# Similar to the Python str[start:end] syntax
+target = 'x86_FreeBSD'
+platform = target.substring(0, 3) # prefix string value 'x86'
+system = target.substring(4) # suffix string value 'FreeBSD'
+```
+
+The method accepts negative values where negative `start` is relative to the end of
+string `len(string) - start` as well as negative `end`.
+
+```meson
+string = 'foobar'
+target.substring(-5, -3) # => 'oo'
+target.substring(1, -1) # => 'ooba'
+```
+
+#### .split(), .join()
 
 ```meson
 # Similar to the Python str.split()
@@ -246,7 +281,7 @@ api_version = '@0@.@1@'.format(version_array[0], version_array[1])
 # api_version now (again) has the value '0.2'
 ```
 
-**.underscorify()**
+#### .underscorify()
 
 ```meson
 name = 'Meson Docs.txt#Reference-manual'
@@ -256,7 +291,7 @@ underscored = name.underscorify()
 # underscored now has the value 'Meson_Docs_txt_Reference_manual'
 ```
 
-**.version_compare()**
+#### .version_compare()
 
 ```meson
 version = '1.2.3'
@@ -266,8 +301,15 @@ is_new = version.version_compare('>=2.0')
 # Supports the following operators: '>', '<', '>=', '<=', '!=', '==', '='
 ```
 
-Arrays
---
+Meson version comparison conventions include:
+
+```meson
+'3.6'.version_compare('>=3.6.0') == false
+```
+
+It is best to be unambiguous and specify the full revision level to compare.
+
+## Arrays
 
 Arrays are delimited by brackets. An array can contain an arbitrary number of objects of any type.
 
@@ -302,6 +344,7 @@ assign it to `my_array` instead of modifying the original since all
 objects in Meson are immutable.
 
 Since 0.49.0, you can check if an array contains an element like this:
+
 ```meson
 my_array = [1, 2]
 if 1 in my_array
@@ -312,7 +355,7 @@ if 1 not in my_array
 endif
 ```
 
-#### Array methods
+### Array methods
 
 The following methods are defined for all arrays:
 
@@ -320,8 +363,7 @@ The following methods are defined for all arrays:
  - `contains`, returns `true` if the array contains the object given as argument, `false` otherwise
  - `get`, returns the object at the given index, negative indices count from the back of the array, indexing out of bounds is a fatal error. Provided for backwards-compatibility, it is identical to array indexing.
 
-Dictionaries
---
+## Dictionaries
 
 Dictionaries are delimited by curly braces. A dictionary can contain an
 arbitrary number of key value pairs. Keys are required to be strings, values can
@@ -346,6 +388,7 @@ Visit the [Reference Manual](Reference-manual.md#dictionary-object) to read
 about the methods exposed by dictionaries.
 
 Since 0.49.0, you can check if a dictionary contains a key like this:
+
 ```meson
 my_dict = {'foo': 42, 'bar': 43}
 if 'foo' in my_dict
@@ -361,14 +404,14 @@ endif
 
 *Since 0.53.0* Keys can be any expression evaluating to a string value, not limited
 to string literals any more.
+
 ```meson
 d = {'a' + 'b' : 42}
 k = 'cd'
 d += {k : 43}
 ```
 
-Function calls
---
+## Function calls
 
 Meson provides a set of usable functions. The most common use case is
 creating build objects.
@@ -413,8 +456,7 @@ executable('progname', 'prog.c',
 
 Attempting to do this causes Meson to immediately exit with an error.
 
-Method calls
---
+## Method calls
 
 Objects can have methods, which are called with the dot operator. The
 exact methods it provides depends on the object.
@@ -424,8 +466,7 @@ myobj = some_function()
 myobj.do_something('now')
 ```
 
-If statements
---
+## If statements
 
 If statements work just like in other languages.
 
@@ -446,8 +487,7 @@ if opt != 'foo'
 endif
 ```
 
-Logical operations
---
+## Logical operations
 
 Meson has the standard range of logical operations which can be used in
 `if` statements.
@@ -537,8 +577,7 @@ endforeach
 # result is ['a', 'b']
 ```
 
-Comments
---
+## Comments
 
 A comment starts with the `#` character and extends until the end of the line.
 
@@ -547,8 +586,7 @@ some_function() # This is a comment
 some_other_function()
 ```
 
-Ternary operator
---
+## Ternary operator
 
 The ternary operator works just like in other languages.
 
@@ -560,8 +598,7 @@ The only exception is that nested ternary operators are forbidden to
 improve legibility. If your branching needs are more complex than this
 you need to write an `if/else` construct.
 
-Includes
---
+## Includes
 
 Most source trees have multiple subdirectories to process. These can
 be handled by Meson's `subdir` command. It changes to the given
@@ -576,8 +613,7 @@ test_data_dir = 'data'
 subdir('tests')
 ```
 
-User-defined functions and methods
---
+## User-defined functions and methods
 
 Meson does not currently support user-defined functions or
 methods. The addition of user-defined functions would make Meson
@@ -588,3 +624,71 @@ FAQ](FAQ.md#why-is-meson-not-just-a-python-module-so-i-could-code-my-build-setup
 because of this limitation you find yourself copying and pasting code
 a lot you may be able to use a [`foreach` loop
 instead](#foreach-statements).
+
+## Stability Promises
+
+Meson is very actively developed and continuously improved. There is a
+possibility that future enhancements to the Meson build system will require
+changes to the syntax. Such changes might be the addition of new reserved
+keywords, changing the meaning of existing keywords or additions around the
+basic building blocks like statements and fundamental types. It is planned
+to stabilize the syntax with the 1.0 release.
+
+## Grammar
+
+This is the full Meson grammar, as it is used to parse Meson build definition files:
+
+```
+additive_expression: multiplicative_expression | (additive_expression additive_operator multiplicative_expression)
+additive_operator: "+" | "-"
+argument_list: positional_arguments ["," keyword_arguments] | keyword_arguments
+array_literal: "[" [expression_list] "]"
+assignment_expression: conditional_expression | (logical_or_expression assignment_operator assignment_expression)
+assignment_operator: "=" | "*=" | "/=" | "%=" | "+=" | "-="
+boolean_literal: "true" | "false"
+build_definition: (NEWLINE | statement)*
+condition: expression
+conditional_expression: logical_or_expression | (logical_or_expression "?" expression ":" assignment_expression
+decimal_literal: DECIMAL_NUMBER
+DECIMAL_NUMBER: /[1-9][0-9]*/
+dictionary_literal: "{" [key_value_list] "}"
+equality_expression: relational_expression | (equality_expression equality_operator relational_expression)
+equality_operator: "==" | "!="
+expression: assignment_expression
+expression_list: expression ("," expression)*
+expression_statememt: expression
+function_expression: id_expression "(" [argument_list] ")"
+hex_literal: "0x" HEX_NUMBER
+HEX_NUMBER: /[a-fA-F0-9]+/
+id_expression: IDENTIFIER
+IDENTIFIER: /[a-zA-Z_][a-zA-Z_0-9]*/
+identifier_list: id_expression ("," id_expression)*
+integer_literal: decimal_literal | octal_literal | hex_literal
+iteration_statement: "foreach" identifier_list ":" id_expression NEWLINE (statement | jump_statement)* "endforeach"
+jump_statement: ("break" | "continue") NEWLINE
+key_value_item: expression ":" expression
+key_value_list: key_value_item ("," key_value_item)*
+keyword_item: id_expression ":" expression
+keyword_arguments: keyword_item ("," keyword_item)*
+literal: integer_literal | string_literal | boolean_literal | array_literal | dictionary_literal
+logical_and_expression: equality_expression | (logical_and_expression "and" equality_expression)
+logical_or_expression: logical_and_expression | (logical_or_expression "or" logical_and_expression)
+method_expression: postfix_expression "." function_expression
+multiplicative_expression: unary_expression | (multiplicative_expression multiplicative_operator unary_expression)
+multiplicative_operator: "*" | "/" | "%"
+octal_literal: "0o" OCTAL_NUMBER
+OCTAL_NUMBER: /[0-7]+/
+positional_arguments: expression ("," expression)*
+postfix_expression: primary_expression | subscript_expression | function_expression | method_expression
+primary_expression: literal | ("(" expression ")") | id_expression
+relational_expression: additive_expression | (relational_expression relational_operator additive_expression)
+relational_operator: ">" | "<" | ">=" | "<=" | "in" | ("not" "in")
+selection_statement: "if" condition NEWLINE (statement)* ("elif" condition NEWLINE (statement)*)* ["else" (statement)*] "endif"
+statement: (expression_statement | selection_statement | iteration_statement) NEWLINE
+string_literal: ("'" STRING_SIMPLE_VALUE "'") | ("'''" STRING_MULTILINE_VALUE "'''")
+STRING_MULTILINE_VALUE: \.*?(''')\
+STRING_SIMPLE_VALUE: \.*?(?<!\\)(\\\\)*?'\
+subscript_expression: postfix_expression "[" expression "]"
+unary_expression: postfix_expression | (unary_operator unary_expression)
+unary_operator: "not" | "+" | "-"
+```
diff --git a/docs/markdown/Tutorial.md b/docs/markdown/Tutorial.md
index 6b248b5..c5a4e6b 100644
--- a/docs/markdown/Tutorial.md
+++ b/docs/markdown/Tutorial.md
@@ -74,7 +74,7 @@ Now we are ready to build our code.
 
 ```
 $ cd builddir
-$ ninja
+$ meson compile
 ```
 
 Once that is done we can run the resulting binary.
@@ -124,12 +124,12 @@ or the like. Instead we just type the exact same command as if we were
 rebuilding our code without any build system changes.
 
 ```
-$ ninja
+$ meson compile
 ```
 
 Once you have set up your build directory the first time, you don't
 ever need to run the `meson` command again. You always just run
-`ninja`. Meson will automatically detect when you have done changes to
+`meson compile`. Meson will automatically detect when you have done changes to
 build definitions and will take care of everything so users don't have
 to care. In this case the following output is produced.
 
diff --git a/docs/markdown/Unit-tests.md b/docs/markdown/Unit-tests.md
index 0785549..60fcad2 100644
--- a/docs/markdown/Unit-tests.md
+++ b/docs/markdown/Unit-tests.md
@@ -4,20 +4,24 @@ short-description: Meson's own unit-test system
 
 # Unit tests
 
-Meson comes with a fully functional unit test system. To use it simply build an executable and then use it in a test.
+Meson comes with a fully functional unit test system. To use it simply build
+an executable and then use it in a test.
 
 ```meson
 e = executable('prog', 'testprog.c')
 test('name of test', e)
 ```
 
-You can add as many tests as you want. They are run with the command `ninja test`.
+You can add as many tests as you want. They are run with the command `meson
+test`.
 
-Meson captures the output of all tests and writes it in the log file `meson-logs/testlog.txt`.
+Meson captures the output of all tests and writes it in the log file
+`meson-logs/testlog.txt`.
 
 ## Test parameters
 
-Some tests require the use of command line arguments or environment variables. These are simple to define.
+Some tests require the use of command line arguments or environment
+variables. These are simple to define.
 
 ```meson
 test('command line test', exe, args : ['first', 'second'])
@@ -29,48 +33,59 @@ Note how you need to specify multiple values as an array.
 ### MALLOC_PERTURB_
 
 By default, environment variable
-[`MALLOC_PERTURB_`](http://man7.org/linux/man-pages/man3/mallopt.3.html)
-is set to a random value between 1..255. This can help find memory
-leaks on configurations using glibc, including with non-GCC compilers.
-This feature can be disabled as discussed in [test()](Reference-manual.md#test).
+[`MALLOC_PERTURB_`](http://man7.org/linux/man-pages/man3/mallopt.3.html) is
+set to a random value between 1..255. This can help find memory leaks on
+configurations using glibc, including with non-GCC compilers. This feature
+can be disabled as discussed in [test()](Reference-manual.md#test).
 
 ## Coverage
 
 If you enable coverage measurements by giving Meson the command line flag
-`-Db_coverage=true`, you can generate coverage reports after running the tests
-(running the tests is required to gather the list of functions that get
-called). Meson will autodetect what coverage generator tools you have installed
-and will generate the corresponding targets. These targets are `coverage-xml`
-and `coverage-text` which are both provided by [Gcovr](http://gcovr.com)
-(version 3.3 or higher) and `coverage-html`, which requires
-[Lcov](https://ltp.sourceforge.io/coverage/lcov.php) and
-[GenHTML](https://linux.die.net/man/1/genhtml) or
-[Gcovr](http://gcovr.com). As a convenience, a high-level `coverage` target is
-also generated which will produce all 3 coverage report types, if possible.
-
-The output of these commands is written to the log directory `meson-logs` in your build directory.
+`-Db_coverage=true`, you can generate coverage reports after running the
+tests (running the tests is required to gather the list of functions that get
+called). Meson will autodetect what coverage generator tools you have
+installed and will generate the corresponding targets. These targets are
+`coverage-xml` and `coverage-text` which are both provided by
+[Gcovr](http://gcovr.com) (version 3.3 or higher) and `coverage-html`, which
+requires [Lcov](https://ltp.sourceforge.io/coverage/lcov.php) and
+[GenHTML](https://linux.die.net/man/1/genhtml) or [Gcovr](http://gcovr.com).
+As a convenience, a high-level `coverage` target is also generated which will
+produce all 3 coverage report types, if possible.
+
+The output of these commands is written to the log directory `meson-logs` in
+your build directory.
 
 ## Parallelism
 
-To reduce test times, Meson will by default run multiple unit tests in parallel. It is common to have some tests which can not be run in parallel because they require unique hold on some resource such as a file or a D-Bus name. You have to specify these tests with a keyword argument.
+To reduce test times, Meson will by default run multiple unit tests in
+parallel. It is common to have some tests which can not be run in parallel
+because they require unique hold on some resource such as a file or a D-Bus
+name. You have to specify these tests with a keyword argument.
 
 ```meson
 test('unique test', t, is_parallel : false)
 ```
 
-Meson will then make sure that no other unit test is running at the same time. Non-parallel tests take longer to run so it is recommended that you write your unit tests to be parallel executable whenever possible.
+Meson will then make sure that no other unit test is running at the same
+time. Non-parallel tests take longer to run so it is recommended that you
+write your unit tests to be parallel executable whenever possible.
 
-By default Meson uses as many concurrent processes as there are cores on the test machine. You can override this with the environment variable `MESON_TESTTHREADS` like this.
+By default Meson uses as many concurrent processes as there are cores on the
+test machine. You can override this with the environment variable
+`MESON_TESTTHREADS` like this.
 
 ```console
-$ MESON_TESTTHREADS=5 ninja test
+$ MESON_TESTTHREADS=5 meson test
 ```
 
 ## Priorities
 
 *(added in version 0.52.0)*
 
-Tests can be assigned a priority that determines when a test is *started*. Tests with higher priority are started first, tests with lower priority started later. The default priority is 0, meson makes no guarantee on the ordering of tests with identical priority.
+Tests can be assigned a priority that determines when a test is *started*.
+Tests with higher priority are started first, tests with lower priority
+started later. The default priority is 0, meson makes no guarantee on the
+ordering of tests with identical priority.
 
 ```meson
 test('started second', t, priority : 0)
@@ -78,23 +93,36 @@ test('started third', t, priority : -50)
 test('started first', t, priority : 1000)
 ```
 
-Note that the test priority only affects the starting order of tests and subsequent tests are affected by how long it takes previous tests to complete. It is thus possible that a higher-priority test is still running when lower-priority tests with a shorter runtime have completed.
+Note that the test priority only affects the starting order of tests and
+subsequent tests are affected by how long it takes previous tests to
+complete. It is thus possible that a higher-priority test is still running
+when lower-priority tests with a shorter runtime have completed.
 
 ## Skipped tests and hard errors
 
 Sometimes a test can only determine at runtime that it can not be run.
 
-For the default `exitcode` testing protocol, the GNU standard approach in this case is to exit the program with error code 77. Meson will detect this and report these tests as skipped rather than failed. This behavior was added in version 0.37.0.
+For the default `exitcode` testing protocol, the GNU standard approach in
+this case is to exit the program with error code 77. Meson will detect this
+and report these tests as skipped rather than failed. This behavior was added
+in version 0.37.0.
 
-For TAP-based tests, skipped tests should print a single line starting with `1..0 # SKIP`.
+For TAP-based tests, skipped tests should print a single line starting with
+`1..0 # SKIP`.
 
-In addition, sometimes a test fails set up so that it should fail even if it is marked as an expected failure. The GNU standard approach in this case is to exit the program with error code 99. Again, Meson will detect this and report these tests as `ERROR`, ignoring the setting of `should_fail`. This behavior was added in version 0.50.0.
+In addition, sometimes a test fails set up so that it should fail even if it
+is marked as an expected failure. The GNU standard approach in this case is
+to exit the program with error code 99. Again, Meson will detect this and
+report these tests as `ERROR`, ignoring the setting of `should_fail`. This
+behavior was added in version 0.50.0.
 
 ## Testing tool
 
-The goal of the meson test tool is to provide a simple way to run tests in a variety of different ways. The tool is designed to be run in the build directory.
+The goal of the meson test tool is to provide a simple way to run tests in a
+variety of different ways. The tool is designed to be run in the build
+directory.
 
-The simplest thing to do is just to run all tests, which is equivalent to running `ninja test`.
+The simplest thing to do is just to run all tests.
 
 ```console
 $ meson test
@@ -107,7 +135,7 @@ For clarity, consider the meson.build containing:
 ```meson
 
 test('A', ..., suite: 'foo')
-test('B', ..., suite: 'foo')
+test('B', ..., suite: ['foo', 'bar'])
 test('C', ..., suite: 'bar')
 test('D', ..., suite: 'baz')
 
@@ -125,7 +153,8 @@ Tests belonging to a suite `suite` can be run as follows
 $ meson test --suite (sub)project_name:suite
 ```
 
-Since version *0.46*, `(sub)project_name` can be omitted if it is the top-level project.
+Since version *0.46*, `(sub)project_name` can be omitted if it is the
+top-level project.
 
 Multiple suites are specified like:
 
@@ -145,7 +174,8 @@ Sometimes you need to run the tests multiple times, which is done like this:
 $ meson test --repeat=10
 ```
 
-Invoking tests via a helper executable such as Valgrind can be done with the `--wrap` argument
+Invoking tests via a helper executable such as Valgrind can be done with the
+`--wrap` argument
 
 ```console
 $ meson test --wrap=valgrind testname
@@ -163,17 +193,25 @@ Meson also supports running the tests under GDB. Just doing this:
 $ meson test --gdb testname
 ```
 
-Meson will launch `gdb` all set up to run the test. Just type `run` in the GDB command prompt to start the program.
+Meson will launch `gdb` all set up to run the test. Just type `run` in the
+GDB command prompt to start the program.
 
-The second use case is a test that segfaults only rarely. In this case you can invoke the following command:
+The second use case is a test that segfaults only rarely. In this case you
+can invoke the following command:
 
 ```console
 $ meson test --gdb --repeat=10000 testname
 ```
 
-This runs the test up to 10 000 times under GDB automatically. If the program crashes, GDB will halt and the user can debug the application. Note that testing timeouts are disabled in this case so `meson test` will not kill `gdb` while the developer is still debugging it. The downside is that if the test binary freezes, the test runner will wait forever.
+This runs the test up to 10 000 times under GDB automatically. If the program
+crashes, GDB will halt and the user can debug the application. Note that
+testing timeouts are disabled in this case so `meson test` will not kill
+`gdb` while the developer is still debugging it. The downside is that if the
+test binary freezes, the test runner will wait forever.
 
-Sometimes, the GDB binary is not in the PATH variable or the user wants to use a GDB replacement. Therefore, the invoked GDB program can be specified *(added 0.52.0)*:
+Sometimes, the GDB binary is not in the PATH variable or the user wants to
+use a GDB replacement. Therefore, the invoked GDB program can be specified
+*(added 0.52.0)*:
 
 ```console
 $ meson test --gdb --gdb-path /path/to/gdb testname
@@ -183,12 +221,41 @@ $ meson test --gdb --gdb-path /path/to/gdb testname
 $ meson test --print-errorlogs
 ```
 
-Meson will report the output produced by the failing tests along with other useful information as the environmental variables. This is useful, for example, when you run the tests on Travis-CI, Jenkins and the like.
+Meson will report the output produced by the failing tests along with other
+useful information as the environmental variables. This is useful, for
+example, when you run the tests on Travis-CI, Jenkins and the like.
 
-For further information see the command line help of Meson by running `meson test -h`.
+For further information see the command line help of Meson by running `meson
+test -h`.
 
 ## Legacy notes
 
-If `meson test` does not work for you, you likely have a old version of Meson.
-In that case you should call `mesontest` instead. If `mesontest` doesn't work
-either you have a very old version prior to 0.37.0 and should upgrade.
+If `meson test` does not work for you, you likely have a old version of
+Meson. In that case you should call `mesontest` instead. If `mesontest`
+doesn't work either you have a very old version prior to 0.37.0 and should
+upgrade.
+
+## Test outputs
+
+Meson will write several different files with detailed results of running
+tests. These will be written into $builddir/meson-logs/
+
+### testlog.json
+
+This is not a proper json file, but a file containing one valid json object
+per line. This is file is designed so each line is streamed out as each test
+is run, so it can be read as a stream while the test harness is running
+
+### testlog.junit.xml
+
+This is a valid JUnit XML description of all tests run. It is not streamed
+out, and is written only once all tests complete running.
+
+When tests use the `tap` protocol each test will be recorded as a testsuite
+container, with each case named by the number of the result.
+
+When tests use the `gtest` protocol meson will inject arguments to the test
+to generate it's own JUnit XML, which meson will include as part of this XML
+file.
+
+*New in 0.55.0*
diff --git a/docs/markdown/Users.md b/docs/markdown/Users.md
index bfc8a7a..50cd27a 100644
--- a/docs/markdown/Users.md
+++ b/docs/markdown/Users.md
@@ -56,6 +56,7 @@ topic](https://github.com/topics/meson).
  - [GtkDApp](https://gitlab.com/csoriano/GtkDApp), an application template for developing Flatpak apps with Gtk+ and D
  - [GVfs](https://git.gnome.org/browse/gvfs/), a userspace virtual filesystem designed to work with the I/O abstraction of GIO
  - [Hardcode-Tray](https://github.com/bil-elmoussaoui/Hardcode-Tray), fixes hardcoded tray icons in Linux
+ - [HarfBuzz](https://github.com/harfbuzz/harfbuzz), a text shaping engine
  - [HelenOS](http://helenos.org), a portable microkernel-based multiserver operating system
  - [HexChat](https://github.com/hexchat/hexchat), a cross-platform IRC client in C
  - [IGT](https://gitlab.freedesktop.org/drm/igt-gpu-tools), Linux kernel graphics driver test suite
@@ -70,8 +71,10 @@ topic](https://github.com/topics/meson).
  - [Knot Resolver](https://gitlab.labs.nic.cz/knot/knot-resolver), Full caching DNS resolver implementation
  - [Ksh](https://github.com/att/ast), a Korn Shell
  - [Lc0](https://github.com/LeelaChessZero/lc0), LeelaChessZero is a UCI-compliant chess engine designed to play chess via neural network
+ - [Le](https://github.com/kirushyk/le), machine learning framework
  - [libcamera](https://git.linuxtv.org/libcamera.git/), a library to handle complex cameras on Linux, ChromeOS and Android
  - [Libdrm](https://gitlab.freedesktop.org/mesa/drm), a library for abstracting DRM kernel interfaces
+ - [libeconf](https://github.com/openSUSE/libeconf), Enhanced config file parsing library, which merges config files placed in several locations into one
  - [Libepoxy](https://github.com/anholt/libepoxy/), a library for handling OpenGL function pointer management
  - [libfuse](https://github.com/libfuse/libfuse), the reference implementation of the Linux FUSE (Filesystem in Userspace) interface
  - [Libgit2-glib](https://git.gnome.org/browse/libgit2-glib), a GLib wrapper for libgit2
@@ -115,6 +118,7 @@ format files
  - [RxDock](https://gitlab.com/rxdock/rxdock), a protein-ligand docking software designed for high throughput virtual screening (fork of rDock)
  - [scrcpy](https://github.com/Genymobile/scrcpy), a cross platform application that provides display and control of Android devices connected on USB or over TCP/IP
  - [Sequeler](https://github.com/Alecaddd/sequeler), a friendly SQL client for Linux, built with Vala and Gtk
+ - [Siril](https://gitlab.com/free-astro/siril), an image processing software for amateur astronomy
  - [SSHFS](https://github.com/libfuse/sshfs), allows you to mount a remote filesystem using SFTP
  - [sway](https://github.com/swaywm/sway), i3-compatible Wayland compositor
  - [Sysprof](https://git.gnome.org/browse/sysprof), a profiling tool
@@ -124,6 +128,7 @@ format files
  - [Terminology](https://github.com/billiob/terminology), a terminal emulator based on the Enlightenment Foundation Libraries
  - [Tilix](https://github.com/gnunn1/tilix), a tiling terminal emulator for Linux using GTK+ 3
  - [Tizonia](https://github.com/tizonia/tizonia-openmax-il), a command-line cloud music player for Linux with support for Spotify, Google Play Music, YouTube, SoundCloud, TuneIn, Plex servers and Chromecast devices
+ - [Vala Language Server](https://github.com/benwaffle/vala-language-server), code intelligence engine for the Vala and Genie programming languages
  - [Valum](https://github.com/valum-framework/valum), a micro web framework written in Vala
  - [Venom](https://github.com/naxuroqa/Venom), a modern Tox client for the GNU/Linux desktop
  - [VMAF](https://github.com/Netflix/vmaf) (by Netflix), a perceptual video quality assessment based on multi-method fusion
diff --git a/docs/markdown/Using-multiple-build-directories.md b/docs/markdown/Using-multiple-build-directories.md
index 2455640..ab6cf3c 100644
--- a/docs/markdown/Using-multiple-build-directories.md
+++ b/docs/markdown/Using-multiple-build-directories.md
@@ -32,9 +32,9 @@ You can add cross builds, too. As an example, let's set up a Linux -> Windows cr
     mkdir buildwine
     meson --cross-file=mingw-cross.txt buildwine
 
-The cross compilation file sets up Wine so that not only can you compile your application, you can also run the unit test suite just by issuing the command `ninja test`.
+The cross compilation file sets up Wine so that not only can you compile your application, you can also run the unit test suite just by issuing the command `meson test`.
 
-To compile any of these build types, just cd into the corresponding build directory and run `ninja` or instruct your IDE to do the same. Note that once you have set up your build directory once, you can just run Ninja and Meson will ensure that the resulting build is fully up to date according to the source. Even if you have not touched one of the directories in weeks and have done major changes to your build configuration, Meson will detect this and bring the build directory up to date (or print an error if it can't do that). This allows you to do most of your work in the default directory and use the others every now and then without having to babysit your build directories.
+To compile any of these build types, just cd into the corresponding build directory and run `meson compile` or instruct your IDE to do the same. Note that once you have set up your build directory once, you can just run Ninja and Meson will ensure that the resulting build is fully up to date according to the source. Even if you have not touched one of the directories in weeks and have done major changes to your build configuration, Meson will detect this and bring the build directory up to date (or print an error if it can't do that). This allows you to do most of your work in the default directory and use the others every now and then without having to babysit your build directories.
 
 ## Specialized uses
 
diff --git a/docs/markdown/Vala.md b/docs/markdown/Vala.md
index cbb58a9..0a29847 100644
--- a/docs/markdown/Vala.md
+++ b/docs/markdown/Vala.md
@@ -237,7 +237,7 @@ dependencies = [
     dependency('glib-2.0'),
     dependency('gobject-2.0'),
     meson.get_compiler('c').find_library('foo'),
-    meson.get_compiler('vala').find_library('foo', dir: vapi_dir),
+    meson.get_compiler('vala').find_library('foo', dirs: vapi_dir),
 ]
 
 sources = files('app.vala')
diff --git a/docs/markdown/Vs-External.md b/docs/markdown/Vs-External.md
index add089e..ab3d191 100644
--- a/docs/markdown/Vs-External.md
+++ b/docs/markdown/Vs-External.md
@@ -23,9 +23,9 @@ as follows:
 
 | entry | value |
 | ----- | ----- |
-|build  | `ninja -C $(Configuration)` |
-|clean  | `ninja -C $(Configuration) clean` |
-|rebuild| `ninja -C $(Configuration) clean all|
+|build  | `meson compile -C $(Configuration)` |
+|clean  | `meson compile -C $(Configuration) --clean` |
+|rebuild| `meson compile -C $(Configuration) --clean && meson compile -C $(Configuration)` |
 |Output | `$(Configuration)\name_of_your_executable.exe|
 
 
diff --git a/docs/markdown/Wrap-dependency-system-manual.md b/docs/markdown/Wrap-dependency-system-manual.md
index 6e47d58..8e6282e 100644
--- a/docs/markdown/Wrap-dependency-system-manual.md
+++ b/docs/markdown/Wrap-dependency-system-manual.md
@@ -28,16 +28,16 @@ itself in a way that makes it easy to use (usually this means as a
 static library).
 
 To use this kind of a project as a dependency you could just copy and
-extract it inside your project's `subprojects` directory. 
+extract it inside your project's `subprojects` directory.
 
 However there is a simpler way. You can specify a Wrap file that tells Meson
-how to download it for you. If you then use this subproject in your build, 
+how to download it for you. If you then use this subproject in your build,
 Meson will automatically download and extract it during build. This makes
 subproject embedding extremely easy.
 
 All wrap files must have a name of `<project_name>.wrap` form and be in `subprojects` dir.
 
-Currently Meson has four kinds of wraps: 
+Currently Meson has four kinds of wraps:
 - wrap-file
 - wrap-git
 - wrap-hg
@@ -70,19 +70,31 @@ revision = head
 ## Accepted configuration properties for wraps
 - `directory` - name of the subproject root directory, defaults to the name of the wrap.
 
+Since *0.55.0* those can be used in all wrap types, they were previously reserved to `wrap-file`:
+
+- `patch_url` - download url to retrieve an optional overlay archive
+- `patch_fallback_url` - fallback URL to be used when download from `patch_url` fails *Since: 0.55.0*
+- `patch_filename` - filename of the downloaded overlay archive
+- `patch_hash` - sha256 checksum of the downloaded overlay archive
+- `patch_directory` - *Since 0.55.0* Overlay directory, alternative to `patch_filename` in the case
+  files are local instead of a downloaded archive. The directory must be placed in
+  `subprojects/packagefiles`.
+
 ### Specific to wrap-file
 - `source_url` - download url to retrieve the wrap-file source archive
 - `source_fallback_url` - fallback URL to be used when download from `source_url` fails *Since: 0.55.0*
 - `source_filename` - filename of the downloaded source archive
 - `source_hash` - sha256 checksum of the downloaded source archive
-- `patch_url` - download url to retrieve an optional overlay archive
-- `patch_fallback_url` - fallback URL to be used when download from `patch_url` fails *Since: 0.55.0*
-- `patch_filename` - filename of the downloaded overlay archive
-- `patch_hash` - sha256 checksum of the downloaded overlay archive
 - `lead_directory_missing` - for `wrap-file` create the leading
   directory name. Needed when the source file does not have a leading
   directory.
 
+Since *0.55.0* it is possible to use only the `source_filename` and
+`patch_filename` value in a .wrap file (without `source_url` and `patch_url`) to
+specify a local archive in the `subprojects/packagefiles` directory. The `*_hash`
+entries are optional when using this method. This method should be prefered over
+the old `packagecache` approach described below.
+
 Since *0.49.0* if `source_filename` or `patch_filename` is found in the
 project's `subprojects/packagecache` directory, it will be used instead
 of downloading the file, even if `--wrap-mode` option is set to
@@ -94,7 +106,7 @@ of downloading the file, even if `--wrap-mode` option is set to
   valid value (such as a git tag) for the VCS's `checkout` command, or
   (for git) `head` to track upstream's default branch. Required.
 
-## Specific to wrap-git
+### Specific to wrap-git
 - `depth` - shallowly clone the repository to X number of commits. Note
   that git always allow shallowly cloning branches, but in order to
   clone commit ids shallowly, the server must support
@@ -124,19 +136,106 @@ thousands of lines of code. Once you have a working build definition,
 just zip up the Meson build files (and others you have changed) and
 put them somewhere where you can download them.
 
-Meson build patches are only supported for wrap-file mode. When using
-wrap-git, the repository must contain all Meson build definitions.
+Prior to *0.55.0* Meson build patches were only supported for wrap-file mode.
+When using wrap-git, the repository must contain all Meson build definitions.
+Since *0.55.0* Meson build patches are supported for any wrap modes, including
+wrap-git.
+
+## `provide` section
+
+*Since *0.55.0*
+
+Wrap files can define the dependencies it provides in the `[provide]` section.
+
+```ini
+[provide]
+dependency_names = foo-1.0
+```
+
+When a wrap file provides the dependency `foo-1.0`, as above, any call to
+`dependency('foo-1.0')` will automatically fallback to that subproject even if
+no `fallback` keyword argument is given. A wrap file named `foo.wrap` implicitly
+provides the dependency name `foo` even when the `[provide]` section is missing.
+
+Optional dependencies, like `dependency('foo-1.0', required: get_option('foo_opt'))`
+where `foo_opt` is a feature option set to `auto`, will not fallback to the
+subproject defined in the wrap file, for 2 reasons:
+- It allows for looking the dependency in other ways first, for example using
+  `cc.find_library('foo')`, and only fallback if that fails:
+
+```meson
+# this won't use fallback defined in foo.wrap
+foo_dep = dependency('foo-1.0', required: false)
+if not foo_dep.found()
+  foo_dep = cc.find_library('foo', has_headers: 'foo.h', required: false)
+  if not foo_dep.found()
+    # This will use the fallback
+    foo_dep = dependency('foo-1.0')
+    # or
+    foo_dep = dependency('foo-1.0', required: false, fallback: 'foo')
+  endif
+endif
+```
+
+- Sometimes not-found dependency is preferable to a fallback when the feature is
+  not explicitly requested by the user. In that case
+  `dependency('foo-1.0', required: get_option('foo_opt'))` will only fallback
+  when the user sets `foo_opt` to `enabled` instead of `auto`.
+
+If it is desired to fallback for an optional dependency, the `fallback` keyword
+argument must be passed explicitly. For example
+`dependency('foo-1.0', required: get_option('foo_opt'), fallback: 'foo')` will
+use the fallback even when `foo_opt` is set to `auto`.
+
+This mechanism assumes the subproject calls `meson.override_dependency('foo-1.0', foo_dep)`
+so Meson knows which dependency object should be used as fallback. Since that
+method was introduced in version *0.54.0*, as a transitional aid for projects
+that do not yet make use of it the variable name can be provided in the wrap file
+with entries in the format `foo-1.0 = foo_dep`.
+
+For example when using a recent enough version of glib that uses
+`meson.override_dependency()` to override `glib-2.0`, `gobject-2.0` and `gio-2.0`,
+a wrap file would look like:
+```ini
+[wrap-git]
+url=https://gitlab.gnome.org/GNOME/glib.git
+revision=glib-2-62
+
+[provide]
+dependency_names = glib-2.0, gobject-2.0, gio-2.0
+```
+
+With older version of glib dependency variable names need to be specified:
+```ini
+[wrap-git]
+url=https://gitlab.gnome.org/GNOME/glib.git
+revision=glib-2-62
+
+[provide]
+glib-2.0=glib_dep
+gobject-2.0=gobject_dep
+gio-2.0=gio_dep
+```
+
+Programs can also be provided by wrap files, with the `program_names` key:
+```ini
+[provide]
+program_names = myprog, otherprog
+```
+
+With such wrap file, `find_program('myprog')` will automatically fallback to use
+the subproject, assuming it uses `meson.override_find_program('myprog')`.
 
 ## Using wrapped projects
 
-Wraps provide a convenient way of obtaining a project into your subproject directory. 
+Wraps provide a convenient way of obtaining a project into your subproject directory.
 Then you use it as a regular subproject (see [subprojects](Subprojects.md)).
 
 ## Getting wraps
 
-Usually you don't want to write your wraps by hand. 
+Usually you don't want to write your wraps by hand.
 
-There is an online repository called [WrapDB](https://wrapdb.mesonbuild.com) that provides 
+There is an online repository called [WrapDB](https://wrapdb.mesonbuild.com) that provides
 many dependencies ready to use. You can read more about WrapDB [here](Using-the-WrapDB.md).
 
 There is also a Meson subcommand to get and manage wraps (see [using wraptool](Using-wraptool.md)).
diff --git a/docs/markdown/Wrap-maintainer-tools.md b/docs/markdown/Wrap-maintainer-tools.md
new file mode 100644
index 0000000..717d0d2
--- /dev/null
+++ b/docs/markdown/Wrap-maintainer-tools.md
@@ -0,0 +1,17 @@
+# Wrap maintainer tools
+
+The [mesonwrap repository](https://github.com/mesonbuild/mesonwrap) provides tools
+to maintain the WrapDB. Read-only features such can be used by anyone without Meson admin rights.
+
+## Personal access token
+
+Some tools require access to the Github API.
+A [personal access token](https://github.com/settings/tokens) may be required
+if the freebie Github API quota is exhausted. `public_repo` scope is required
+for write operations.
+
+```
+$ cat ~/.config/mesonwrap.ini
+[mesonwrap]
+github_token = <github token>
+```
diff --git a/docs/markdown/Wrap-review-guidelines.md b/docs/markdown/Wrap-review-guidelines.md
index 512353c..3e41a8d 100644
--- a/docs/markdown/Wrap-review-guidelines.md
+++ b/docs/markdown/Wrap-review-guidelines.md
@@ -7,18 +7,30 @@ package is rejected. What should be done will be determined on a
 case-by-case basis. Similarly meeting all these requirements does not
 guarantee that the package will get accepted. Use common sense.
 
-## Checklist
-
-Reviewer: copy-paste this to MR discussion box and tick all boxes that apply.
-
-    - [ ] project() has version string
-    - [ ] project() has license string
-    - [ ] if new project, master has tagged commit as only commit
-    - [ ] if new branch, it is branched from master
-    - [ ] contains a readme.txt
-    - [ ] contains an upstream.wrap file
-    - [ ] download link points to authoritative upstream location
-    - [ ] wrap repository contains only build system files
-    - [ ] merge request is pointed to correct target branch (not master)
-    - [ ] wrap works
-    - [ ] repo does not have useless top level directory (i.e. libfoobar-1.0.0)
+The review process is partially automated by the [mesonwrap](Wrap-maintainer-tools.md)
+`review` tool.
+
+```
+mesonwrap review zlib --pull-request=1 [--approve]
+```
+
+Since not every check can be automated please pay attention to the following during the review:
+
+- Download link points to an authoritative upstream location.
+- Version branch is created from master.
+- Except for the existing code, `LICENSE.build` is mandatory.
+- `project()` has a version and it matches the source version.
+- `project()` has a license.
+- Complex `configure_file()` inputs are documented.
+  If the file is a copy of a project file make sure it is clear what was changed.
+- Unit tests are enabled if the project provides them.
+- There are no guidelines if `install()` is a good or a bad thing in wraps.
+- If the project can't be tested on the host platform consider using the `--cross-file` flag.
+  See [the issue](https://github.com/mesonbuild/mesonwrap/issues/125).
+
+Encourage wrap readability. Use your own judgement.
+
+## Approval
+
+If the code looks good use the `--approve` flag to merge it.
+The tool automatically creates a release.
diff --git a/docs/markdown/howtox.md b/docs/markdown/howtox.md
index 8231d3d..0d1a2a2 100644
--- a/docs/markdown/howtox.md
+++ b/docs/markdown/howtox.md
@@ -25,7 +25,7 @@ for the host platform in cross builds can only be specified with a cross file.
 There is a table of all environment variables supported [Here](Reference-tables.md#compiler-and-linker-selection-variables)
 
 
-## Set dynamic linker
+## Set linker
 
 *New in 0.53.0*
 
@@ -148,15 +148,14 @@ $ meson <other flags> -Db_coverage=true
 Then issue the following commands.
 
 ```console
-$ ninja
-$ ninja test
-$ ninja coverage-html (or coverage-xml)
+$ meson compile
+$ meson test
+$ meson compile coverage-html (or coverage-xml)
 ```
 
 The coverage report can be found in the meson-logs subdirectory.
 
-Note: Currently, Meson does not support generating coverage reports
-with Clang.
+*New in 0.55.0* llvm-cov support for use with clang
 
 ## Add some optimization to debug builds
 
@@ -191,14 +190,14 @@ test failures.
 Install scan-build and configure your project. Then do this:
 
 ```console
-$ ninja scan-build
+$ meson compile scan-build
 ```
 
 You can use the `SCANBUILD` environment variable to choose the
 scan-build executable.
 
 ```console
-$ SCANBUILD=<your exe> ninja scan-build
+$ SCANBUILD=<your exe> meson compile scan-build
 ```
 
 
@@ -209,8 +208,8 @@ operation. First we set up the project with profile measurements
 enabled and compile it.
 
 ```console
-$ meson  <Meson options, such as --buildtype=debugoptimized> -Db_pgo=generate
-$ ninja -C builddir
+$ meson setup <Meson options, such as --buildtype=debugoptimized> -Db_pgo=generate
+$ meson compile -C builddir
 ```
 
 Then we need to run the program with some representative input. This
@@ -221,7 +220,7 @@ information and rebuild.
 
 ```console
 $ meson configure -Db_pgo=use
-$ ninja
+$ meson compile
 ```
 
 After these steps the resulting binary is fully optimized.
@@ -260,3 +259,28 @@ The `cmake_module_path` property is only needed for custom CMake scripts. System
 wide CMake scripts are found automatically.
 
 More information can be found [here](Dependencies.md#cmake)
+
+## Get a default not-found dependency?
+
+```meson
+null_dep = dependency('', required : false)
+```
+
+This can be used in cases where you want a default value, but might override it
+later.
+
+```meson
+# Not needed on Windows!
+my_dep = dependency('', required : false)
+if host_machine.system() in ['freebsd', 'netbsd', 'openbsd', 'dragonfly']
+  my_dep = dependency('some dep', required : false)
+elif host_machine.system() == 'linux'
+  my_dep = dependency('some other dep', required : false)
+endif
+
+executable(
+  'myexe',
+  my_sources,
+  deps : [my_dep]
+)
+```
diff --git a/docs/markdown/legal.md b/docs/markdown/legal.md
index bd86ff4..a14b7b9 100644
--- a/docs/markdown/legal.md
+++ b/docs/markdown/legal.md
@@ -12,7 +12,7 @@ specific permission. It is not licensed under the same terms as the
 rest of the project.
 
 If you are a third party and want to use the Meson logo, you must
-first must obtain written permission from Jussi Pakkanen.
+first obtain written permission from Jussi Pakkanen.
 
 ## Website licensing
 
diff --git a/docs/markdown/snippets/dist_not_tests.md b/docs/markdown/snippets/dist_not_tests.md
deleted file mode 100644
index f9c971e..0000000
--- a/docs/markdown/snippets/dist_not_tests.md
+++ /dev/null
@@ -1,5 +0,0 @@
-## meson dist --no-tests
-
-`meson dist` has a new option `--no-tests` to skip build and tests of generated
-packages. It can be used to not waste time for example when done in CI that
-already does its own testing.
diff --git a/docs/markdown/snippets/keyval.md b/docs/markdown/snippets/keyval.md
new file mode 100644
index 0000000..895de9b
--- /dev/null
+++ b/docs/markdown/snippets/keyval.md
@@ -0,0 +1,7 @@
+## `unstable-keyval` is now stable `keyval`
+
+The `unstable-keyval` has been renamed to `keyval` and now promises stability
+guarantees.
+
+Meson will print a warning when you load an `unstable-` module that has been
+stabilised (so `unstable-keyval` is still accepted for example).
diff --git a/docs/markdown/snippets/per_subproject.md b/docs/markdown/snippets/per_subproject.md
new file mode 100644
index 0000000..6de6068
--- /dev/null
+++ b/docs/markdown/snippets/per_subproject.md
@@ -0,0 +1,4 @@
+## Per subproject `warning_level` option
+
+`warning_level` can now be defined per subproject, in the same way as
+`default_library` and `werror`.
diff --git a/docs/markdown/snippets/project_options_in_machine_files.md b/docs/markdown/snippets/project_options_in_machine_files.md
new file mode 100644
index 0000000..8dab951
--- /dev/null
+++ b/docs/markdown/snippets/project_options_in_machine_files.md
@@ -0,0 +1,52 @@
+## Project and built-in options can be set in native or cross files
+
+A new set of sections has been added to the cross and native files, `[project
+options]` and `[<subproject_name>:project options]`, where `subproject_name`
+is the name of a subproject. Any options that are allowed in the project can
+be set from this section. They have the lowest precedent, and will be
+overwritten by command line arguments.
+
+
+```meson
+option('foo', type : 'string', value : 'foo')
+```
+
+```ini
+[project options]
+foo = 'other val'
+```
+
+```console
+meson build --native-file my.ini
+```
+
+Will result in the option foo having the value `other val`,
+
+```console
+meson build --native-file my.ini -Dfoo='different val'
+```
+
+Will result in the option foo having the value `different val`,
+
+
+Subproject options are assigned like this:
+
+```ini
+[zlib:project options]
+foo = 'some val'
+```
+
+Additionally meson level options can be set in the same way, using the
+`[built-in options]` section.
+
+```ini
+[built-in options]
+c_std = 'c99'
+```
+
+These options can also be set on a per-subproject basis, although only
+`default_library` and `werror` can currently be set:
+```ini
+[zlib:built-in options]
+default_library = 'static'
+```
diff --git a/docs/markdown/snippets/wrap_fallback.md b/docs/markdown/snippets/wrap_fallback.md
deleted file mode 100644
index 9b71143..0000000
--- a/docs/markdown/snippets/wrap_fallback.md
+++ /dev/null
@@ -1,4 +0,0 @@
-## Wrap fallback URL
-
-Wrap files can now define `source_fallback_url` and `patch_fallback_url` to be
-used in case the main server is temporaly down.
diff --git a/docs/markdown_dynamic/Commands.md b/docs/markdown_dynamic/Commands.md
new file mode 100644
index 0000000..a35b4da
--- /dev/null
+++ b/docs/markdown_dynamic/Commands.md
@@ -0,0 +1,296 @@
+# Command-line commands
+
+There are two different ways of invoking Meson. First, you can run it directly
+from the source tree with the command `/path/to/source/meson.py`. Meson may
+also be installed in which case the command is simply `meson`. In this manual
+we only use the latter format for simplicity.
+
+Meson is invoked using the following syntax:
+`meson [COMMAND] [COMMAND_OPTIONS]`
+
+This section describes all available commands and some of their Optional arguments.
+The most common workflow is to run [`setup`](#setup), followed by [`compile`](#compile), and then [`install`](#install).
+
+For the full list of all available options for a specific command use the following syntax:
+`meson COMMAND --help`
+
+### configure
+
+```
+{{ cmd_help['configure']['usage'] }}
+```
+
+Changes options of a configured meson project.
+
+```
+{{ cmd_help['configure']['arguments'] }}
+```
+
+Most arguments are the same as in [`setup`](#setup).
+
+Note: reconfiguring project will not reset options to their default values (even if they were changed in `meson.build`).
+
+#### Examples:
+
+List all available options:
+```
+meson configure builddir
+```
+
+Change value of a single option:
+```
+meson configure builddir -Doption=new_value
+```
+
+### compile
+
+*(since 0.54.0)*
+
+```
+{{ cmd_help['compile']['usage'] }}
+```
+
+Builds a default or a specified target of a configured meson project.
+
+```
+{{ cmd_help['compile']['arguments'] }}
+```
+
+`--verbose` argument is available since 0.55.0.
+
+#### Targets
+
+*(since 0.55.0)*
+
+`TARGET` has the following syntax `[PATH/]NAME[:TYPE]`, where:
+- `NAME`: name of the target from `meson.build` (e.g. `foo` from `executable('foo', ...)`).
+- `PATH`: path to the target relative to the root `meson.build` file. Note: relative path for a target specified in the root `meson.build` is `./`.
+- `TYPE`: type of the target. Can be one of the following: 'executable', 'static_library', 'shared_library', 'shared_module', 'custom', 'run', 'jar'.
+  
+`PATH` and/or `TYPE` can be ommited if the resulting `TARGET` can be used to uniquely identify the target in `meson.build`.
+
+#### Backend specific arguments
+
+*(since 0.55.0)*
+
+`BACKEND-args` use the following syntax:
+
+If you only pass a single string, then it is considered to have all values separated by commas. Thus invoking the following command:
+
+```
+$ meson compile --ninja-args=-n,-d,explain
+```
+
+would add `-n`, `-d` and `explain` arguments to ninja invocation.
+
+If you need to have commas or spaces in your string values, then you need to pass the value with proper shell quoting like this:
+
+```
+$ meson compile "--ninja-args=['a,b', 'c d']"
+```
+
+#### Examples:
+
+Build the project:
+```
+meson compile -C builddir
+```
+
+Execute a dry run on ninja backend with additional debug info:
+```
+meson compile --ninja-args=-n,-d,explain
+```
+
+Build three targets: two targets that have the same `foo` name, but different type, and a `bar` target:
+```
+meson compile foo:shared_library foo:static_library bar
+```
+
+Produce a coverage html report (if available):
+```
+meson compile coverage-html
+```
+
+### dist
+
+*(since 0.52.0)*
+
+```
+{{ cmd_help['dist']['usage'] }}
+```
+
+Generates a release archive from the current source tree.
+
+```
+{{ cmd_help['dist']['arguments'] }}
+```
+
+See [notes about creating releases](Creating-releases.md) for more info.
+
+#### Examples:
+
+Create a release archive:
+```
+meson dist -C builddir
+```
+
+### init
+
+*(since 0.45.0)*
+
+```
+{{ cmd_help['init']['usage'] }}
+```
+
+Creates a basic set of build files based on a template.
+
+```
+{{ cmd_help['init']['arguments'] }}
+```
+
+#### Examples:
+
+Create a project in `sourcedir`:
+```
+meson init -C sourcedir
+```
+
+### introspect
+
+```
+{{ cmd_help['introspect']['usage'] }}
+```
+
+Displays information about a configured meson project.
+
+```
+{{ cmd_help['introspect']['arguments'] }}
+```
+
+#### Examples:
+
+Display basic information about a configured project in `builddir`:
+```
+meson introspect builddir
+```
+
+### install
+
+*(since 0.47.0)*
+
+```
+{{ cmd_help['install']['usage'] }}
+```
+
+Installs the project to the prefix specified in [`setup`](#setup).
+
+```
+{{ cmd_help['install']['arguments'] }}
+```
+
+See [the installation documentation](Installing.md) for more info.
+
+#### Examples:
+
+Install project to `prefix`:
+```
+meson install -C builddir
+```
+
+Install project to `$DESTDIR/prefix`:
+```
+DESTDIR=/path/to/staging/area meson install -C builddir
+```
+
+### rewrite
+
+*(since 0.50.0)*
+
+```
+{{ cmd_help['rewrite']['usage'] }}
+```
+
+Modifies the meson project.
+
+```
+{{ cmd_help['rewrite']['arguments'] }}
+```
+
+See [the meson file rewriter documentation](Rewriter.md) for more info.
+
+### setup
+
+```
+{{ cmd_help['setup']['usage'] }}
+```
+
+Configures a build directory for the meson project.
+
+This is the default meson command (invoked if there was no COMMAND supplied).
+
+```
+{{ cmd_help['setup']['arguments'] }}
+```
+
+See [meson introduction page](Running-Meson.md#configuring-the-build-directory) for more info.
+
+#### Examples:
+
+Configures `builddir` with default values:
+```
+meson setup builddir
+```
+
+### subprojects
+
+*(since 0.49.0)*
+
+```
+{{ cmd_help['subprojects']['usage'] }}
+```
+
+Manages subprojects of the meson project.
+
+```
+{{ cmd_help['subprojects']['arguments'] }}
+```
+
+### test
+
+```
+{{ cmd_help['test']['usage'] }}
+```
+
+Run tests for the configure meson project.
+
+```
+{{ cmd_help['test']['arguments'] }}
+```
+
+See [the unit test documentation](Unit-tests.md) for more info.
+
+#### Examples:
+
+Run tests for the project:
+```
+meson test -C builddir
+```
+
+Run only `specific_test_1` and `specific_test_2`:
+```
+meson test -C builddir specific_test_1 specific_test_2
+```
+
+### wrap
+
+```
+{{ cmd_help['wrap']['usage'] }}
+```
+
+An utility to manage WrapDB dependencies.
+
+```
+{{ cmd_help['wrap']['arguments'] }}
+```
+
+See [the WrapDB tool documentation](Using-wraptool.md) for more info.
diff --git a/docs/meson.build b/docs/meson.build
index 32aab07..c07a200 100644
--- a/docs/meson.build
+++ b/docs/meson.build
@@ -1,16 +1,40 @@
 project('Meson documentation', version: '1.0')
 
+cur_bdir = meson.current_build_dir()
+
+# Copy all files to build dir, since HotDoc uses relative paths
+run_command(
+    files('../tools/copy_files.py'),
+    '-C', meson.current_source_dir(),
+    '--output-dir', cur_bdir,
+    'markdown', 'theme', 'sitemap.txt', 
+    check: true)
+
+# Only the script knows which files are being generated
+docs_gen = custom_target(
+    'gen_docs',
+    input: files('markdown/index.md'),
+    output: 'gen_docs.dummy',
+    command: [
+        files('../tools/regenerate_docs.py'),
+        '--output-dir', join_paths(cur_bdir, 'markdown'),
+        '--dummy-output-file', '@OUTPUT@',
+    ],
+    build_by_default: true,
+    install: false)
+
 hotdoc = import('hotdoc')
 documentation = hotdoc.generate_doc(meson.project_name(),
     project_version: meson.project_version(),
-    sitemap: 'sitemap.txt',
+    sitemap: join_paths(cur_bdir, 'sitemap.txt'),
     build_by_default: true,
-    index: 'markdown/index.md',
+    depends: docs_gen,
+    index: join_paths(cur_bdir, 'markdown/index.md'),
     install: false,
     extra_assets: ['images/'],
-    include_paths: ['markdown'],
+    include_paths: [join_paths(cur_bdir, 'markdown')],
     default_license: 'CC-BY-SAv4.0',
-    html_extra_theme: join_paths('theme', 'extra'),
+    html_extra_theme: join_paths(cur_bdir, 'theme', 'extra'),
     git_upload_repository: 'git@github.com:jpakkane/jpakkane.github.io.git',
     edit_on_github_repository: 'https://github.com/mesonbuild/meson/',
     syntax_highlighting_activate: true,
diff --git a/docs/sitemap.txt b/docs/sitemap.txt
index 3ac138e..ac74870 100644
--- a/docs/sitemap.txt
+++ b/docs/sitemap.txt
@@ -5,6 +5,7 @@ index.md
 	Manual.md
 		Overview.md
 		Running-Meson.md
+		Commands.md
 		Builtin-options.md
 		Using-with-Visual-Studio.md
 		Meson-sample.md
@@ -48,7 +49,7 @@ index.md
 			SourceSet-module.md
 			Windows-module.md
 			Cuda-module.md
-			Kconfig-module.md
+			Keyval-module.md
 		Java.md
 		Vala.md
 		D.md
@@ -72,11 +73,13 @@ index.md
 		Adding-new-projects-to-wrapdb.md
 		Using-the-WrapDB.md
 		Using-wraptool.md
+		Wrap-maintainer-tools.md
 		Wrap-best-practices-and-tips.md
 		Wrap-review-guidelines.md
 		Shipping-prebuilt-binaries-as-wraps.md
 		fallback-wraptool.md
 	Release-notes.md
+		Release-notes-for-0.55.0.md
 		Release-notes-for-0.54.0.md
 		Release-notes-for-0.53.0.md
 		Release-notes-for-0.52.0.md
@@ -116,5 +119,6 @@ index.md
 		Using-multiple-build-directories.md
 		Vs-External.md
 	Contributing.md
+		MesonCI.md
 	legal.md
 	Videos.md
diff --git a/docs/theme/extra/templates/navbar_links.html b/docs/theme/extra/templates/navbar_links.html
index 6980f81..832bd2c 100644
--- a/docs/theme/extra/templates/navbar_links.html
+++ b/docs/theme/extra/templates/navbar_links.html
@@ -14,7 +14,7 @@
 					 ("Hotdoc-module.html","Hotdoc"), \
 					 ("i18n-module.html","i18n"), \
 					 ("Icestorm-module.html","Icestorm"), \
-					 ("Kconfig-module.html","kconfig"), \
+					 ("Keyval-module.html","Keyval"), \
            ("Pkgconfig-module.html","Pkgconfig"), \
            ("Python-module.html","Python"), \
            ("Python-3-module.html","Python 3"), \